• In our demo presentation, we have been told that a user joining a garden's event without being a member of the garden doesn't make sense as a user that is not the member of the garden won't be knowing any people from the garden and what is going on there, so why would they join the event? We took this feedback as a sign that we should be making what the gardens are about more explicitly available to non-member users.

• We have been told that the live data population of our app was not realistic enough. Although we had prepared our data carefully and as realistic as possible and we think that this feedback might be given to us by mistake, we took this as an opportunity to create even more realistic data in our app. Our mock users are communicating through forum with nearby users, following them, joining their gardens and events.

• We have been told that our web app has no instructions and the mobile app could not reach the deployed API. We had all the required instructions on the home page of our repository but we interpreted this feedback as our instructions not being clear enough, so we rewrote the README of our repository in much more detail and explanation so that customers / developers can easily access our project.

• Lastly, we have been told that we were not using GitHub Projects, and again, we were indeed using it. But seeing the dissatisfaction of the customers by the appearance of our workflow, we are planning to improve our formalism by integrating new PR reviewing templates and guidelines for our developers, better tracking of issues, and making use of subissues, etc.

Deliverable	Description / Link	Status
Revised Software Requirements Specification (SRS)	SRS	Done
Revised Software Design (UML Diagrams)	Software Design	Done
Communication Plan	Communication Plan	Done
Contribution Guidelines	Contribution Guidelines	Done
Project Plan	Project Plan	Done
Weekly Reports and Meeting Notes	Meeting Reports	Done
Milestone Review	MVP Milestone Report	Done
Individual Contributions	Individual Contributions	Done
Pre-release Version of Software	Release Tag	Done

All planned deliverables—including the revised SRS, updated UML design, communication and contribution guidelines, project plan, weekly reports, milestone review, and individual contribution summaries—have been completed on time. The pre-release version has also been successfully tagged, reflecting the integration of recent features, bug fixes, and improvements across frontend, backend, and mobile platforms.

The completion of these deliverables confirms that development progress is aligned with the project plan. No critical delays were introduced, and the scope of work remains consistent with initial expectations. The finalized documents and stable pre-release build provide a solid foundation for the upcoming final milestone and reduce risks related to planning, coordination, and implementation.

GitHub: Enabled seamless team collaboration and version control. It was central to managing our codebase, reviewing changes via pull requests, and tracking issues.

Docker: By packaging our application into containers, it made running and deploying the app significantly easier using docker-compose.

Google Cloud Platform (GCP): Provided a reliable and easy-to-use infrastructure for hosting our application's backend, database and frontend.

Expo: Dramatically accelerated our mobile app development, allowing us to build and test the mobile app quickly.

Django DB Migration: Simplified database schema updates. It let us easily apply, track, and reverse changes to our application's database models in a controlled way.

Postman: Was essential for testing and debugging our API. It let us quickly send various requests and inspect the backend's responses to verify all endpoints worked correctly.

GitHub Copilot: Sped up our coding process significantly by providing intelligent, context-aware code suggestions, which helped reduce boilerplate and solve problems faster.

ESLint / Prettier: Enforced consistent code quality and style in frontend project. These tools automatically formatted our code and caught potential bugs early, improving readability.

HackMD: Served as our central hub for collaborative documentation, allowing us to write technical specifications, user stories, and meeting notes together in real-time.

Firestore: Allowed us to implement our real time chat system efficiently. Its low latency synchronization and document based model made handling chat messages, conversations, and updates easy.

Firebase Cloud Messaging: Used for reliable and scalable push notifications for both mobile and web. FCM was important for delivering real time updates such as feed notifications to users.

Selenium: Used for end-to-end (E2E) testing of our application. It allowed us to simulate real user interactions across different browsers, validate full user workflows, and ensure that critical features functioned correctly from frontend to backend.

Requirement Number	Description	Status
1.1	Users shall be able to register and create an account using email, username, name, surname, password, and optional location information.	⏮ COMPLETED PREVIOUSLY
1.2	The system shall allow users to log in and log out securely.	⏮ COMPLETED PREVIOUSLY
1.3	Users shall be able to edit all their profile information.	⏮ COMPLETED PREVIOUSLY
1.4	Users shall be able to upload optional profile pictures.	⏮ COMPLETED PREVIOUSLY
1.5	Users shall be able to follow other users.	⏮ COMPLETED PREVIOUSLY
1.6	Users shall be able to filter the forum feed to display only posts from users they follow.	✅ COMPLETED
1.7	The system shall recommend nearby gardens for users who provided their location information.	✅ COMPLETED
2.1	The system shall allow users to create, assign, update, and delete gardening tasks.	⏮ COMPLETED PREVIOUSLY
2.2	Users shall be able to track task progress with status updates (e.g., "Pending," "In Progress," "Completed").	⏮ COMPLETED PREVIOUSLY
2.3	The system shall provide a set of predefined task types (system-defined) and users shall have the option to create custom (user-defined) task types.	✅ COMPLETED
2.4	The system shall have tasks with a title, description, and optional deadline.	⏮ COMPLETED PREVIOUSLY
2.5	The system shall allow users to assign multiple assignees to tasks.	❌ NOT STARTED
2.6	The system shall support tasks without assignees, allowing users to self-assign on a voluntary basis.	⏮ COMPLETED PREVIOUSLY
2.7	Users shall be able to accept or decline tasks assigned to them.	⏮ COMPLETED PREVIOUSLY
2.8	The system shall send task notifications to assigned users.	✅ COMPLETED
2.9	The system shall send notifications to task assigners about acceptance or decline of the task.	✅ COMPLETED
3.1	The system shall allow users to schedule periodical tasks with a period of choice.	❌ NOT STARTED
3.2	The system shall support a calendar structure for periodic and aperiodic tasks based on periods and deadlines.	⏮ COMPLETED PREVIOUSLY
4.1	The system shall integrate with a weather API to fetch real-time weather data.	⏮ COMPLETED PREVIOUSLY
4.2	Users shall receive automated gardening reminders based on weather conditions from API.	⏱️ IN PROGRESS
5.1	Users shall be able to create, edit, and delete discussion posts.	⏮ COMPLETED PREVIOUSLY
5.2	Users shall be able to comment on forum posts.	⏮ COMPLETED PREVIOUSLY
5.3	The system shall provide system administrators and moderators with moderation rights, including the ability to delete inappropriate content.	✅ COMPLETED
5.4	The system shall provide moderators with authorization to delete inappropriate content and manage user reports.	✅ COMPLETED
5.5	The system shall provide read-only access to public forum posts for guests.	⏮ COMPLETED PREVIOUSLY
5.6	Members shall be able to report inappropriate posts and users to moderators.	⏱️ IN PROGRESS
6.1	The system shall in-app notifications for task updates, weather alerts, receiving followers and forum activity.	✅ COMPLETED
6.2	Users shall have the option to enable or disable notifications.	✅ COMPLETED
6.3	The system shall send notifications for tasks nearing their deadlines.	✅ COMPLETED
6.4	The system shall send notifications to garden managers upon a member requests to join their garden.	✅ COMPLETED
6.5	The system shall send notifications to garden members upon being accepted to the garden.	✅ COMPLETED
7.1.1	The system shall have distinct roles: System Administrator, Moderator, Member, and Guest.	⏮ COMPLETED PREVIOUSLY
7.1.2.1	The system shall have a single or a limited number of System Administrator(s) with full control over the platform.	✅ COMPLETED
7.1.2.2	The system shall let System Administrator(s) manage every forum post on the platform.	✅ COMPLETED
7.1.2.3	The system shall let System Administrator(s) manage any title in any garden.	✅ COMPLETED
7.1.2.4	The system shall let System Administrator(s) have the authority to close gardens if abuse of the software is detected.	✅ COMPLETED
7.1.2.5	The system shall let System Administrator(s) manage Moderators and system-related issues exclusively.	✅ COMPLETED
7.1.3.1	The system shall support a variable number of Moderators.	✅ COMPLETED
7.1.3.2	The system shall let Moderators manage forum content, including deleting inappropriate posts and comments.	✅ COMPLETED
7.1.3.3	The system shall let Moderators receive user reports and take appropriate actions.	✅ COMPLETED
7.1.3.4	The system shall let Moderators remove gardens based on user reports or observed violations.	⏱️ IN PROGRESS
7.1.3.5	The system shall let Moderators ban users who abuse the system.	⏱️ IN PROGRESS
7.1.4.1	Users who register to the platform shall automatically become Members.	⏮ COMPLETED PREVIOUSLY
7.1.4.2	The system shall let Members request to join a garden.	⏮ COMPLETED PREVIOUSLY
7.1.4.3	The system shall let Members leave a garden.	⏮ COMPLETED PREVIOUSLY
7.1.4.4	The system shall let Members create a garden.	⏮ COMPLETED PREVIOUSLY
7.1.4.5	The system shall let Members create, assign, and track tasks within the gardens they manage.	⏮ COMPLETED PREVIOUSLY
7.1.4.6	The system shall let Members create and comment on forum posts.	⏮ COMPLETED PREVIOUSLY
7.1.4.7	The system shall let Members edit only their own profile information.	⏮ COMPLETED PREVIOUSLY
7.1.4.8	The system shall let Members accept or decline tasks assigned to them.	⏮ COMPLETED PREVIOUSLY
7.1.5.1	The system shall let Guests (users without an account) have read-only access to public forum posts.	⏮ COMPLETED PREVIOUSLY
7.1.5.2	The system shall let Guests have read-only access to basic garden information (garden name, location etc.).	⏮ COMPLETED PREVIOUSLY
7.1.5.3	The system shall not let Guests create or edit tasks.	⏮ COMPLETED PREVIOUSLY
7.1.5.4	The system shall let Guests upgrade to Member status via the registration process.	⏮ COMPLETED PREVIOUSLY
7.2.1.1	The user who creates a garden shall automatically become the Manager of that garden.	⏮ COMPLETED PREVIOUSLY
7.2.1.2	The system shall let Managers assign tasks to members of the garden.	⏮ COMPLETED PREVIOUSLY
7.2.1.3	The system shall let Managers accept or remove members from their garden.	⏮ COMPLETED PREVIOUSLY
7.2.1.4	The system shall let Managers appoint other Members as additional Managers of the garden.	⏮ COMPLETED PREVIOUSLY
7.2.1.5	The system shall let Managers access to create, modify, and delete tasks.	⏮ COMPLETED PREVIOUSLY
7.2.1.6	The system shall let Managers create custom task types.	⏮ COMPLETED PREVIOUSLY
7.2.2.1	The system shall let Members who are accepted into a garden shall become Workers in that garden.	⏮ COMPLETED PREVIOUSLY
7.2.2.2	The system shall let Workers accept or decline tasks assigned by a Manager.	⏮ COMPLETED PREVIOUSLY
7.2.2.3	The system shall let Workers update the status of tasks assigned to them.	⏮ COMPLETED PREVIOUSLY
7.2.2.4	The system shall allow Workers to create events within their garden.	✅ COMPLETED
8.1.1	The system shall provide a chat section within each garden to support internal communication only among its members.	✅ COMPLETED
8.1.2	The system shall allow Managers to configure chat permissions (e.g., "Manager-only messages" or "All members can write").	❌ NOT STARTED
8.1.3	The system shall display messages in chronological order, including the sender's name and time.	✅ COMPLETED
8.2.1	The system shall allow garden members to create events within the gardens they belong to.	✅ COMPLETED
8.2.2	The system shall allow event creators to define the event title, description, date, and time.	✅ COMPLETED
8.2.3	The system shall allow event creators to set the visibility level of each event as either Private (visible only to garden members) or Public (visible to all platform users).	✅ COMPLETED
8.2.4	The system shall allow users to vote on their attendance decision (e.g., "Going," "Not Going," "Maybe").	✅ COMPLETED
9.1	The system shall handle up to 300 concurrent users.	✅ COMPLETED
9.2	The system shall have a response time for critical actions (task creation, forum posting) less than 2 seconds.	✅ COMPLETED
10.1	The UI must be responsive and comply with accessibility standards.	⏮ COMPLETED PREVIOUSLY
10.2	Users shall be able to navigate the system with minimal training.	⏮ COMPLETED PREVIOUSLY
11.1	The system shall have an uptime of 99.9%.	✅ COMPLETED
11.2	Data backups shall be performed periodically.	⏱️ IN PROGRESS
11.3	The system shall process synchronized data and provide updated information to the user.	⏮ COMPLETED PREVIOUSLY
12.1	The system shall follow a modular architecture to facilitate future updates.	⏮ COMPLETED PREVIOUSLY
12.2	Code documentation shall be maintained for all major modules.	⏮ COMPLETED PREVIOUSLY
13.1	The system shall provide descriptive text alternatives for all non-text content (e.g., images, icons, buttons) to ensure compatibility with assistive technologies such as screen readers.	⏮ COMPLETED PREVIOUSLY
13.2	The system shall utilize ARIA attributes (aria-label, aria-describedby, aria-labelledby) where standard HTML semantics are insufficient to provide meaningful descriptions of interactive components.	⏮ COMPLETED PREVIOUSLY
13.3	The system shall ensure a minimum color contrast ratio of 4.5:1 for standard text and 3:1 for large text and graphical elements, in accordance with WCAG 2.1 AA guidelines.	⏮ COMPLETED PREVIOUSLY
13.4	The system shall provide an optional high-contrast mode that can be toggled by the user to improve visibility for users with visual impairments.	⏮ COMPLETED PREVIOUSLY
13.5	The system shall support complete keyboard navigation for all interactive elements, including task management, forum interactions, and profile actions, using standard keyboard keys (Tab, Shift+Tab, Enter, Space).	⏮ COMPLETED PREVIOUSLY
13.6	The system shall use semantic HTML elements (e.g., , , , , ) to enhance compatibility with assistive technologies and improve document structure.	⏮ COMPLETED PREVIOUSLY
13.7	The system shall undergo accessibility testing using major screen readers (e.g., NVDA, VoiceOver) to verify accurate reading order, label associations, and element roles.	⏱️ IN PROGRESS
13.8	The system shall ensure that all user interface components are responsive and adaptable to a variety of screen sizes and device orientations.	⏮ COMPLETED PREVIOUSLY
13.9	The system shall allow text content and images to be resized up to 200% without loss of functionality, truncation, or layout issues.	❌ NOT STARTED
14.1	The system shall support a broad range of assistive technologies, including but not limited to screen readers, voice control interfaces, and full keyboard-only navigation, to ensure accessibility for users with diverse abilities.	⏮ COMPLETED PREVIOUSLY
14.2	The system shall support a map for addresses to enhance user experience and improve accessibility.	✅ COMPLETED
14.3	The system shall provide configurable user accessibility preferences, including options to adjust font size, color contrast, and interface language.	⏮ COMPLETED PREVIOUSLY
14.4	The system shall offer multiple theme options (light mode, dark mode, and a high-contrast accessibility mode), allowing users to select a display that best suits their visual needs.	⏮ COMPLETED PREVIOUSLY
14.5	The system shall support the inclusion and display of images within garden pages and forum posts to facilitate problem-solving, improve content discoverability, and reduce language barriers.	⏮ COMPLETED PREVIOUSLY
14.6	The system shall support display of images with different resolutions to accomodate for different data accesibility and possible connection problems.	⏮ COMPLETED PREVIOUSLY
15.1	The system shall implement a recognition mechanism that awards badges, achievements, or "Top Contributor" labels to users based on their activity, attended events and engagement within the platform.	✅ COMPLETED
15.2	The system shall support user engagement features such as likes, reactions, and upvotes for forum posts and comments to promote community interaction.	❌ NOT STARTED
15.3	The system shall provide a "best answer" selection feature for forum questions to highlight high-quality contributions.	❌ NOT STARTED
15.4	The system shall deliver in-app notifications to users when their contributions receive engagement (e.g., likes, replies, upvotes) or when activity-based milestones are achieved.	⏱️ IN PROGRESS
15.5	The system shall display personalized feedback indicating the impact of a user's contributions on garden progress (e.g., "Your completed task increased the harvest yield by 20%").	❌ NOT STARTED
15.6	The system shall include impact summaries on user profile pages that visualize cumulative contributions and achievements to encourage ongoing participation.	❌ NOT STARTED
16.1.1	The system shall use a translation framework (e.g., react-i18next) to separate UI text from code and store it in language resource files.	⏮ COMPLETED PREVIOUSLY
16.1.2	The system shall avoid hardcoded text in components; instead, all UI text shall reference translation keys.	⏮ COMPLETED PREVIOUSLY
16.2.1	The system shall support both left-to-right (LTR) and right-to-left (RTL) script layouts.	✅ COMPLETED
16.2.2	The system shall correctly mirror UI layouts for RTL languages such as Arabic or Hebrew.	✅ COMPLETED
16.3.1	The system shall use internationalization APIs (e.g., Intl.DateTimeFormat, Intl.NumberFormat) to display dates, times, numbers, and measurement units according to the user's locale.	⏮ COMPLETED PREVIOUSLY
16.3.2	The system shall store dates and times in a standardized format (e.g., ISO 8601) and convert them to locale-specific formats for display.	⏮ COMPLETED PREVIOUSLY
16.4.1	The system shall include a lang attribute in the root HTML element and dynamically update it based on the selected language.	⏮ COMPLETED PREVIOUSLY
17.1.1	The system shall collect only the minimum personal data necessary for functionality (e.g., username, email, location if provided voluntarily).	⏮ COMPLETED PREVIOUSLY
17.1.2	The system shall apply anonymization or pseudonymization techniques to protect personally identifiable information (PII) wherever feasible (e.g., analytics, reporting).	⏱️ IN PROGRESS
17.1.3	The system shall obtain explicit user consent before collecting or processing personal data.	✅ COMPLETED
17.1.4	The system shall clearly communicate how user data is collected, used, and shared through a transparent Privacy Policy.	✅ COMPLETED
17.1.5	The system shall provide user-controlled privacy settings (e.g., controlling profile visibility, data sharing preferences).	❌ NOT STARTED
17.1.6	The system shall employ masking the exact location of a user and only support neighboring information in order to avoid exposing a user's exact location.	❌ NOT STARTED
17.2.1	The system shall make data flows and system decisions transparent and explainable to users.	✅ COMPLETED
17.2.2	The system shall maintain logs of all significant automated actions to ensure auditability.	✅ COMPLETED
17.2.3	The system shall document the assumptions, limitations, and potential biases of algorithms used.	✅ COMPLETED
17.3.1	The system shall be designed and tested to avoid reinforcing social, cultural, or demographic biases in datasets or user interactions.	✅ COMPLETED
17.3.2	The system shall ensure equitable access and experience for users across diverse demographics, languages, and abilities.	⏮ COMPLETED PREVIOUSLY
17.3.3	The system shall be periodically audited for fairness and unintended harms.	⏱️ IN PROGRESS
17.3.4	All public contributions and user recognition features (e.g., badges, achievements) shall be awarded based on transparent, merit-based criteria.	✅ COMPLETED
17.4.1	All communication shall be encrypted via HTTPS/TLS.	⏮ COMPLETED PREVIOUSLY
17.4.2	Confidential data (e.g. passwords) shall not be stored as plain-text, strong encryption/hashing algorithms shall be used (e.g. SHA-256).	⏮ COMPLETED PREVIOUSLY
17.4.3	The system shall implement multi-layered access control, ensuring that users can access only the data necessary for their role.	⏱️ IN PROGRESS
17.4.4	The system shall enforce strong authentication mechanisms (e.g., multi-factor authentication).	❌ NOT STARTED
17.4.5	The system shall delete location data upon the user's request.	✅ COMPLETED
17.4.6	Regular security audits and penetration tests shall be conducted to assess and enhance the robustness of the platform's security posture.	❌ NOT STARTED
17.4.7	Latest available versions of development tools (frameworks, libraries etc.) shall be used.	✅ COMPLETED
17.4.8	PoLP (Principle of Least Privilege) shall be enforced.	⏱️ IN PROGRESS

During the last milestone, we adopted a more departmentalized approach, assigning team members to focus on tasks for one or a few core features. This strategy significantly reduced cross-team (Frontend, Backend, Mobile) communication overhead and allowed developers to concentrate on their own codebases. Consequently, we observed a faster and more stable development process with fewer bugs.

For the upcoming milestone, we are implementing two key process improvements:

1. Mandatory PR Screenshots: To address the recent need for late-stage bug fixes—which suggests Pull Requests (PRs) may have been merged without adequate testing—we will make adding screenshots of the tested, locally deployed functionality mandatory for all PR reviews.

2. Mobile Team Support: To help the mobile team accelerate their progress, we plan to provide dedicated support. We are currently evaluating the best approach: either assigning a member to the mobile team or offering cross-functional collaborative support.

Our strategy for the Final Milestone is to complete all remaining project requirements. We have prioritized core functionality updates and high-effort tasks for the initial phase. As we approach the end of the milestone, we will shift focus to completing minor enhancements and testing-related activities. Further details can be found in our project plan wiki page and project roadmap.

• We have implemented 3 different color themes for our app, namely: Light Mode, Dark Mode, High Contrast Mode. These color themes aim to help users with different visual needs use our app smoothly. Light and Dark color modes are generic options for users with different environments, and High Contrast Mode aims to help users with visual impairments. In our scenarios, dark color theme was used by a user with migraine and High Contrast Mode was used by a color blind user. All of the color themes also have unit tests that ensure the color contrast ratios are in accordance with the WCAG 2.1 AA guidelines Source.

  • Related Issues: #254, #255, #263
  • Related PRs: #307, #321

• Our web app is fully keyboard navigable, ensuring that users who cannot or prefer not to use a mouse, such as users with motor impairments, temporary injuries, or power-users relying on keyboard efficiency, can access every interactive element through logical tab order.

  • Related Issues: #256
  • Related PRs: #302

• We have implemented text alternatives across our application to ensure accessibility for users with visual impairments. All garden images, profile pictures, and user avatars include descriptive alt attributes that provide meaningful context. Interactive elements such as form fields, buttons, and navigation components are equipped with proper aria-label attributes for screen reader compatibility. Modal dialogs and complex UI components use ARIA attributes (aria-labelledby, aria-describedby) for clear relationships between content and labels. Our implementation supports text alternatives in multiple languages through our internationalization system, so accessibility across different languages in compliance with WCAG 2.1 AA guidelines.

  • Related Issues: #256
  • Related PRs: #302

• We have implemented responsive design across our application to create optimal user experience on all device types and screen sizes. Our system utilizes Material-UI breakpoints (xs, sm, md, lg, xl) with CSS flexbox and Grid layouts to provide adaptive interfaces that easily adjust from mobile devices (0-599px) to large desktop screens (1200px+). Components like TaskBoard and Calendar automatically switch between vertical stacking on mobile and horizontal layouts on desktop. The application supports text and image resizing up to 200% without functionality loss or layout issues, and includes RTL (Right-to-Left) language support with proper UI mirroring for languages such as Arabic. All responsive features are tested across various screen orientations and device types.

  • Related Issues: #258, #348
  • Related PRs: #349

• We have implemented comprehensive internationalization support using the react-i18next framework with standard BCP 47 language tags for both frontend and mobile applications. Our system supports English, Turkish and Arabic languages on web and English and Turkish on mobile, with complete UI text separation from code through translation resource files, eliminating all hardcoded strings in favor of translation keys. The implementation includes proper RTL (Right-to-Left) script support with UI mirroring for languages such as Arabic, and applies locally appropriate formatting for dates using Intl.DateTimeFormat. Language preferences are automatically detected and persistently stored, with dynamic updates to the HTML lang attribute for accessibility compliance. The system covers over 800+ translation keys across all major components including authentication, navigation, garden management, forum, tasks, and profile sections.

  • Related Issues: #236, #261, #262, #266
  • Related PRs: #326, #329, #349

We have written a comprehensive report about why WoT requirement is not suitable for our project and why we are not going to implement it.

Metehan Sarkaç represents a Mediterranean farmer looking to connect with fellow farmers and gardeners. His journey through the Community Garden Planner platform highlights how discovery, communication (chat and forum), event participation, and badge-based recognition work together to support social and community-oriented gardening practices.

• Accessibility:

The platform ensures users with diverse abilities can follow Metehan's journey through multi-modal notification systems (in-app, push, chat indicators) that provide redundant communication channels, benefiting users who miss transient alerts or use assistive technologies. Clear visual hierarchy with consistent navigation (side menu, tabbed interfaces) and actionable notifications that directly link to relevant content reduces cognitive load for all users and aids those using screen readers. Interactive elements like "Request to Join Garden" and "Going" buttons use action-oriented language with proper ARIA labels and keyboard accessibility. On the visual side, the application supports light/dark/high contrast themes, enabling participation across a wide range of visual needs.

• Inclusivity:

The scenario illustrates inclusive design through gradual participation pathways—users may browse before joining. The platform currently supports three languages, enabling cross-cultural engagement. Location-based garden recommendations assist users facing transportation challenges. The badge system (e.g., “Frost Guardian” for seasonal participation, “Festival Sprout” for social engagement) values not only physical labor but multiple forms of contribution, ensuring that users with mobility limitations can receive recognition through event attendance or forum activity.

• Ethical Considerations:

Ethical design decisions appear throughout the flow: users explicitly consent to membership via “Request to Join” instead of being auto-added, and event participation offers “Going,” “Not Going,” and “Maybe,” accommodating changes. Reporting tools mitigate content risks, while contextual privacy settings protect private events. The app limits data collection to essentials (membership status, RSVPs). Celebration-based badge design avoids competitive comparisons, prioritizing community well-being over engagement metrics and supporting informal, culturally authentic communication styles.

We have unit tests for each component and page in the frontend named <component_name>.test.jsx located next to the component. We use vitest with react-testing-library for testing and istanbul for coverage report.

Unit Test Coverage: 68.82%

We have unit tests for each view/serializer in the backend. We use django for testing and coverage for coverage report.

Unit Test Coverage: 95%

We have unit tests for components and pages in the mobile app named <component_name>.test.js located in the __tests__ directory under the same parent directory of the component. We use jest for testing and jest --coverage for coverage report.

Unit Test Coverage: 93.58%

Why did you choose these specific test cases?

• We chose to test individual components (Frontend/Mobile) and models/serializers (Backend) in isolation to ensure that the smallest units of code function correctly before being integrated. This allows for quick feedback and easier debugging.

What user scenarios or potential failure points are they validating?

• Frontend/Mobile: Validating that components render correctly with different props (e.g., GardenBadges earned vs unearned), handle user interactions (e.g., clicking buttons in ForumList), and display correct states (loading, error, success). Failure points include broken UI rendering, incorrect state updates, and unhandled exceptions.
• Backend: Validating data integrity (Models), correct data transformation (Serializers), and business logic (e.g., profile.follow, ReportingSystem). Failure points include invalid data being saved, incorrect calculations, and logic errors in methods.

How do your tests collectively ensure the core functionality of your application?

• By covering a high percentage of statements, unit tests ensure that the building blocks of the application are robust. This minimizes the risk of bugs in individual functions and classes, providing a solid foundation for higher-level features.

We have integration tests for the API of major features like gardens, tasks and users in the backend located in the tests.py file in the APITests class. We use rest_framework.test for testing.

Why did you choose these specific test cases?

• We chose to test API endpoints to verify that different parts of the backend (views, serializers, models, database) work together correctly. These tests simulate real HTTP requests, which is closer to how the frontend interacts with the backend.

What user scenarios or potential failure points are they validating?

• Validating complete user flows such as registering, logging in, creating gardens, joining gardens, posting in forums, and reporting content. Failure points include broken API endpoints, database constraint violations, permission errors (e.g., non-admin accessing admin reports), and incorrect HTTP response codes.

How do your tests collectively ensure the core functionality of your application?

• They ensure that the backend API, which serves as the core logic for both web and mobile apps, is reliable and correctly handles data flow and business rules across multiple layers.

We have end-to-end tests for the frontend, and we use selenium for testing. Documentation for our Selenium testing can be found here.

Why did you choose these specific test cases?

• We used Selenium to simulate real user interactions within the browser. This ensures that the integrated system (Frontend + Backend) works as expected from the user's perspective, catching issues that might be missed by isolated unit or integration tests.

What user scenarios or potential failure points are they validating?

• Validating critical user journeys like "Sign up -> Create Garden -> Add Task" or "Login -> Browse Forum -> Comment". Failure points include navigation issues, broken cross-component interactions, and network integration issues between frontend and backend.

How do your tests collectively ensure the core functionality of your application?

• They provide the final seal of approval by verifying that the application works as a cohesive whole in a production-like environment, ensuring the most critical features are usable by end-users.

We have UI/UX tests for the frontend and mobile written here as manual tests.

Why did you choose these specific test cases?

• Manual tests were chosen to evaluate aspects that are difficult to automate, such as visual aesthetics, usability, and overall user experience.

What user scenarios or potential failure points are they validating?

• Validating the look and feel, responsiveness on different devices, intuitive navigation, and accessibility. Failure points include confusing UI elements, layout shifts, poor color contrast, and janky animations.

How do your tests collectively ensure the core functionality of your application?

• They ensure that the application is not only functional but also usable and enjoyable, which is critical for user retention and satisfaction.

Responsibilities:
My primary responsibilities included full-stack development with a focus on Frontend and Backend integration. I took ownership of implementing the real-time Chat feature across web, backend, and mobile platforms. I implemented user-facing features such as the Infohub page and Terms & Conditions popup, enhanced the notification system with Firebase deeplinks, and participated in code reviews and debugging critical issues in the Task Board and Authentication flows. I was also responsible for establishing the Frontend testing infrastructure by configuring Vitest and implementing comprehensive unit tests.

Main contributions:
My main contributions centered around three key areas: feature development, infrastructure setup, and quality assurance. I implemented the end-to-end Chat feature using real-time messaging with Firestore database from Firebase and an intuitive chat interface on the frontend. I also implemented the Infohub page with full localization support, added a Terms and Conditions popup to the registration flow, and enhanced user engagement by implementing deeplinks in Firebase notifications. Additionally, I resolved several critical bugs including the Task Board drag-and-drop update issue, the "add task" button visibility bug, and authentication context issues on registration. I significantly improved code quality by configuring Vitest for the frontend and writing comprehensive unit tests for over 10 critical components including GardenCard, GardenModal, ImageGallery, PostCard, PostComposer, TaskBoard, and TaskWidget.

Significant issues:

Code-related:

1. Chat Feature Implementation (Issue #357, PR #356): I designed and implemented a complete real-time chat system using Firestore database from Firebase. On the frontend, I built a responsive chat interface with real-time message updates. I coordinated with the mobile team to ensure the chat feature works seamlessly across platforms.

2. Notification Deeplinks (Issue #419, PR #420): I implemented a deeplink system for Firebase notifications that improved user experience significantly. On the backend, I modified notification creation to include deeplink URLs with different patterns for different notification types (e.g., /garden/{id} for invitations, /forum/{id} for comments). On the frontend, I implemented a notification handler that parses deeplink URLs and navigates users to the appropriate page with correct context loaded, transforming notifications into actionable navigation tools.

3. Frontend Testing Infrastructure & Coverage (Issue #365, PR #372): I established a robust testing infrastructure by configuring Vitest with React Testing Library and Istanbul for coverage reporting. I resolved critical i18n integration issues causing test failures and systematically wrote comprehensive unit tests for 10+ components covering rendering, user interactions, loading/error states, and edge cases. I analyzed coverage reports to identify untested code paths and increased the code coverage.

Non-code-related:

1. Manual Testing & Bug Analysis: I conducted extensive manual testing of the frontend application, leading to the discovery and documentation of several critical bugs. Most notably, I identified and analyzed the registration auth context issue (Issue #379), where newly registered users weren't being properly logged in. I documented the bug with reproduction steps and proposed solutions.

2. UI/UX Tests Creation: I created comprehensive UI/UX test scenarios (Issue #446) for the frontend to ensure a high-quality user experience. I designed three detailed test scenarios covering critical user journeys: (1) Garden Discovery → Membership → Event Participation → Badge Unlock, (2) User Registration → InfoHub Exploration → Forum Question → Community Response, and (3) Garden Joining → Task Rejection → Infection Alert → Event & Badge Unlock. Each scenario included detailed step-by-step actions, expected results, and pass/fail criteria, enabling systematic manual testing of the entire user experience across web and mobile platforms.

3. Firebase Infrastructure Setup: I set up both development and production Firebase projects (Issue #401), configuring Firestore database rules, and deployment settings for both environments. I also configured Firebase project settings across all three platforms (frontend, backend, and mobile) to use environment-specific credentials. This complete infrastructure setup enabled real-time chat functionality, push notifications, and provided a safer development environment that prevented accidental data pollution in production.

Pull requests that you have created, merged, or reviewed:

• Created:
  • PR #356: Implemented chat feature for frontend, mobile and backend.
  • PR #353: Added button to filter posts by followed users and backend support.
  • PR #352: Fixed "add task" button visibility logic.
  • PR #351: Fixed task board update bug and backend visibility logic.
  • PR #372: Configured Vitest and added unit tests for multiple components.
  • PR #375: Fixed chat user cache on logout and register auth context.
  • PR #374: Fixed import issue in chat backend.
  • PR #399: Implemented Frontend infohub page with localization.
  • PR #420: Implemented deeplinks for Firebase notifications.
  • PR #402: Implemented terms and conditions popup.
• Reviewed:
  • PR #376: Reviewed and improved changes for Issue #390 (localization/UI).
  • PR #409: Reviewed Swagger API documentation.
  • PR #397: Reviewed frontend unit test improvements.

If you experienced any conflicts regarding the pull requests you have engaged in, briefly summarize the conflicts along with how they were resolved.
I encountered a minor conflict in the chat backend due to file restructuring in another branch (addressed in PR #374). I resolved this by updating the import paths to match the new structure. Generally, conflicts were resolved by communicating with backend team and merging carefully.

Additional information:
I took the initiative to set up complete Firebase infrastructure for both development and production environments, including Firestore rules and deployment configurations, to prevent data conflicts and ensure a stable testing environment for the team.

• Responsibilities: My main responsibilities focused on mobile development and backend code review. I led the implementation of mobile features and actively participated in ensuring code quality through thorough review of backend pull requests. I also contributed to labs and worked closely with team members to maintain development standards across the mobile platform.

• Main Contributions: I implemented the overall mobile application, making it fully ready for the MVP milestone. I developed core mobile features, ensured proper integration with the backend, and coordinated with team members to review and refine the mobile implementation. I also provided valuable feedback on backend pull requests to maintain consistency across the full stack.

• Code-related significant issues:

Issue Name	Issue Link
Garden Events Feature	#361
Badge Implementation on Mobile	#362
Notification Mobile	#395

• Non-code-related significant issues:

Issue Name	Issue Link
Mobile Team Demo Plan	#288
Mobile APK Creation	#387

• Pull requests that you have created, merged, and reviewed:

  • Created:

    PR Name	PR Link
    Mobile Task Utilities with Unit Tests	#381
    Feature/387 APK Creation Configuration	#388
    Mobile Geolocation Feature - Store Locations as Geolocation	#392
    Notifications MOBILE	#396
    Mobile Garden Events Feature	#394
    Mobile Badges Feature	#411
    Bug/Mobile Scenario Fixes	#423
    Mobile APK	#425

  • Reviewed and merged:

    PR Name	PR Link
    Garden Events Implemented in Backend	#373
    Feature/notifications for Web (Frontend)	#376
    Mobile Forum Utilities with Unit Tests	#383
    Mobile Garden Utilities with Unit Tests	#385
    Moderation System Report-ReportReview	#413
    Badge System	#416
    Feature/create missing mobile unit tests and fix the existing ones	#417
    Feature/nearby gardens mobile	#418
    Merge Dev Into Main	#430

  • Conflicts: When conflicts arose in pull requests, I worked with the PR authors to resolve them by merging the latest develop branch into their feature branches. I verified the resolution by testing the updated code in my local environment before approving.

• Additional information:

  • Participated in all lectures and lab sessions, actively contributing to project discussions and sprint planning.
  • Led the mobile development effort, ensuring the application was fully functional and ready for the MVP milestone.
  • Collaborated closely with team members to review the mobile implementation and ensure quality standards.
  • Coordinated with backend developers through code reviews to maintain consistency across platforms.
  • Contributed to documentation updates to reflect the current state of mobile development.

• Responsibilities: My main responsibilities centered on full-stack development across the frontend and backend. I contributed to feature development on both sides of the stack and actively participated in labs. I also helped diagnose and resolve critical issues in the general flows. In addition, I supported the improvement of test coverage by contributing to unit testing and related test implementations.

• Main Contributions: I implemented the full notification system, including both push notifications and in-app delivery. I reviewed and provided feedback on key backend pull requests, ensuring consistency and reliability across the codebase. I contributed to test quality by adding unit tests and scenario tests, and I supported the team by helping diagnose and resolve several critical bugs affecting core functionality.

• Code-related significant issues:

Issue Name	Issue Link
Implement Notifications	#358
Notifications for Web Alerts (UI Improvement)	#390
Extend Notification Types	#404

• Non-code-related significant issues:

Issue Name	Issue Link
Take Meeting 8 Notes	#355
MVP Milestone Report - Parts 2 and 3	#436

• Pull requests that you have created, merged, and reviewed:

  • Created:

    PR Name	PR Link
    Feature/notifications for Web(Frontend) - Comprehensive	#376

  • Reviewed and merged:

    PR Name	PR Link
    Implement Chat Feature for Frontend, Mobile and Backend	#356
    Fixed Pending Members Creating Tasks Bug in Backend	#366
    Fixed Hanging Gardens With No Members	#367
    Fixed Worker Promotion to Manager	#368
    Added Missing Backend Unit Tests, Fixed Import Paths	#370
    Notification System Fix	#421
    Feature/event badges	#424
    Migration Chain Fix	#428
    Merge Dev Into Main	#430

  • Conflicts: Whenever I encountered a conflict in a PR, I requested changes from the assignee, asking them to merge the develop branch into their branch to resolve the conflicts. After that, I tested the new version in my local development setup before giving the final approve.

• Additional information:

  • Participated in lectures and lab sessions, contributing to project planning and task management through the GitHub Projects board.
  • Actively engaged in team discussions to maintain consistent project planning.
  • Updated and refined some necessary wiki documents in order to ensure documentation alignment with the current development status.
  • I always added tests/unit tests to my PRs.

• Responsibilities: My main responsibility on the team was working as a backend developer. I was an active participant in labs and I implemented new features in the backend. I used unit tests to cover the reliability of these new features. I also collaborated with my teammates on fronted to complete these features.

• Main Contributions: I implemented the full badge system, all kinds of badges and a system to get them. I also reviewed my teammates' code to ensure that we had a stable codebase. I also made sure that our code was covered by unit tests.

• Code-related significant issues:

Issue Name	Issue Link
Implement Badges	#359
Event Badges	#422

• Non-code-related significant issues:

Issue Name	Issue Link

• Pull requests that you have created, merged, and reviewed:

  • Created:

    PR Name	PR Link
    Badge System	#416
    Event Badges	#424

  • Reviewed and merged:

    PR Name	PR Link
    Migration Chain Fix	#428

  • Conflicts: I tried to resolve conflicts with communicating with my teammates and choosing the optimal solution to avoid any issues that might come up in the dev branch.

• Additional information:

  • Participated in lab sessions, contributing to our project plan and weekly efforts.
  • Active in team discussions.
  • Always covered my code with unit tests to ensure a stable codebase.

• Responsibilities: I am a frontend developer. I am responsible for implementing / testing / documenting new features on the web application. I am also responsible of taking part in the organizing / planning phase for the project, keeping track of what needs to be done and how much progress we've done so far.

• Main Contributions: I have implemented the garden events feature (One of my teammates had started implementing it briefly but I took over). Fixed / implemented many unit tests for front end, increased the unit test coverage significantly. Implemented end-to-end tests for frontend using Selenium. Contributed fixing many bugs and quick fixes along the way from the 1st milestone to the 2nd.

• Code-related significant issues:

Issue Name	Issue Link
Garden Events Feature	#361
Fixing Unit Tests	#405
E2E tests using Selenium	#377

• Non-code-related significant issues:

Issue Name	Issue Link
Organizing Roadmap & Project	#393
MVP Milestone Report - Part 7	#439
Writing Selenium E2E test documentation	#458

• Pull requests that you have created, merged, and reviewed:

  • Created:

    PR Name	PR Link
    Feature/frontend garden events	#410
    Improve Frontend Unit Tests	#397

  • Reviewed and merged:

    PR Name	PR Link
    Fix task board task update bug	#351
    Show add task button only to accepted members	#352
    Add button to filter posts from followed users	#353
    Feature/gardens near me	#389
    Frontend Info Hub Page	#399
    Frontend Terms & Conditions Popup	#402
    Implement Deeplinks for Push Notifications	#420
    Increase Frontend Unit Test Coverage	#444

  • Conflicts: In our team the author of the PR solves the conflicts and in the 2 PRs that I've authored in this milestone the only conflicts I had was simple not actually conflict conflicts that I've solved by just reading through the code and selecting something against nothing. As I've just mentioned above, I am not aware of the types of conflicts in the PRs that I've reviewed and merged as they were already handled by the author.

• Additional Information:

  • I contributed to the preparation stage to the milestone demo. Scenario creation, deciding what and how to present, etc.

• Responsibilities: My main responsibilities focused on mobile development and mobile scenario presentation in MVP milestone. I also contributed to labs and worked closely with team members to maintain development standards across the mobile platform.

• Main Contributions: I implemented and reviewed mobile application, making it fully ready for the MVP milestone. I coordinated with team members to review and refine the mobile implementation.

• Code-related significant issues:

Issue Name	Issue Link
Garden Recommendation	#246
Unit tests for forum	#382
Unit test for garden	#384

• Non-code-related significant issues:

Issue Name	Issue Link
Mobile Team Demo Plan	#288
MVP Milestone Report - Parts 1 and 4	#435

• Pull requests that you have created, merged, and reviewed:

  • Created:

    PR Name	PR Link
    Forum Tests for mobile	#383
    Garden Tests for mobile	#384
    Nearby Gardens for mobile	#418
    Bug/Mobile Scenario Fixes	#423

  • Reviewed and merged:

    PR Name	PR Link
    Task related tests	#381
    geolocation mobile	#392
    garden events mobile	#394
    notifications mobile	#396
    badge mobile	#411
    moderation system mobile	#415
    Bug/mobile scenario fixes	#423

  • Conflicts: When conflicts arose in pull requests, I worked with the PR authors to resolve them by merging the latest develop branch into their feature branches. I verified the resolution by testing the updated code in my local environment before approving.

• Additional information:

  • Participated in all lectures and lab sessions, actively contributing to project discussions and sprint planning.
  • Led the mobile development effort, ensuring the application was fully functional and ready for the MVP milestone.
  • Collaborated closely with team members to review the mobile implementation and ensure quality standards.
  • Coordinated with backend developers through code reviews to maintain consistency across platforms.
  • Contributed to documentation updates to reflect the current state of mobile development.

Responsibilities: I was primarily responsible for backend development, specifically focusing on the Garden management logic and the Events feature implementation. Additionally, I took charge of Quality Assurance by significantly expanding the backend unit testing suite, setting up API documentation (Swagger), and managing the deployment of the application for the MVP milestone.

Main contributions: My main contributions leading up to Customer Milestone 2 involved stabilizing the core backend logic. I resolved critical logic errors regarding garden membership and persistence (e.g., "zombie" gardens). I implemented the backend architecture for Garden Events and their categories. A major part of my contribution was the overhaul of the testing suite, raising coverage from 77% to 96% and fixing existing failing tests. Finally, I standardized our API documentation by integrating Swagger and handled the MVP deployment.

Significant issues:

Code-related:

1. Issue #363 - Backend Unit Test Expansion & Fixes: I performed a comprehensive overhaul of the backend testing suite. I implemented new tests and fixed existing broken ones, increasing the total test count from 53 to 188 and improving code coverage from 77% to 96%. This ensured the stability of the backend before the milestone.
2. Issue #361 - Implementation of Garden Events: I developed the backend logic for the Garden Events feature. This involved creating the necessary models, views, and serializers to allow users to create and manage events within gardens, a core requirement for the MVP.
3. Issue #317 - Resolution of "Zombie" Garden Bug: I identified and resolved a logic error where gardens were not being deleted after the last member left. This prevented new users from joining or recreating the garden. I patched the logic to ensure proper cleanup of empty garden instances.

Non-code-related:

1. Issue #437 & Issue #438 - MVP Milestone Report Authoring: I authored parts 5 and 6 of the MVP Milestone report, which included evaluating each project requirement's status, creating issues for the not completed requirements and creating an elaborate project plan.
2. Issue #378 - Manual Web Application Testing: I conducted manual black-box testing of the deployed web application. I identified several functional bugs during this process and reported them with reproduction steps, facilitating fixes before the demo.
3. Issue #442 - Project Requirements Revision: I reviewed and revised the formal project requirements. I updated the documentation to accurately reflect changes in scope, implementation details, and feature refinements that occurred as we approached the MVP milestone.

Pull requests:

Created:

• PR #366 (Fix: Join request task bug)
• PR #367 (Fix: Zombie garden deletion)
• PR #368 (Fix: Manager promotion logic)
• PR #370 (Test coverage expansion)
• PR #373 (Garden Events feature)
• PR #409 (Swagger setup)
• PR #410 (Event categories) (Participated)
• PR #428 (Fix: Migration chain)
• PR #430 (Merge Dev Into Main)

Reviewed:

• PR #374 (Backend import fix)
• PR #375 (General bug fix)
• PR #376 (Frontend notifications)

Conflicts and Resolution: During the review of PR #376 (Frontend notifications), I identified that the implementation was inconsistent with our project requirements and customer UX expectations. I requested specific changes to align the notification behavior with our design standards. After the assignee updated the code, I re-reviewed the PR to ensure the conflict was resolved and the user experience was seamless before merging. Restructuring the backend caused the chat feature to malfunction. I collaborated with my teammate in frontend team to resolve the conflict in PR #374.

Additional information:

• Deployment: I managed the update of the deployed application for the MVP milestone (Issue #403).
• API Documentation: I set up Swagger to generate automatic API documentation, facilitating better communication between frontend and backend teams (Issue #407).
• Demo Preparation: I actively participated in defining the scenarios for both the Web and Mobile demos to ensure a smooth presentation flow.

• Responsibilities: My main responsibilities focused on frontend development and design, and keeping my teammates in sync with what we go over on Tuesday lessons. I led the implementation of badges, gardens near me and garden event features for this milestone. I also implemented RTL UI support.

• Main Contributions: I designed the badges and implemented it. I also implemented gardens near me feature and garden events. I also implemented RTL UI support.

• Code-related significant issues:

Issue Name	Issue Link
Garden Events Feature	#361
Gardens Near Me	#360
Garden Badges	#359
RTL UI Support	#348

• Pull requests that you have created, merged, and reviewed:

  • Created:

    PR Name	PR Link
    Gardens Near Me	#389
    RTL UI Support	#349

  • Contributed:

    PR Name	PR Link
    Gardens Events	#410
    Garden Badges	#416

  • Conflicts: We had a problem where git was creating two instances of the same branch when we were working on the same feature/badges branch with Bora. To resolve the conflict we had to delete one of the branches, get dev on top of the another, and completely clone the project from scratch.

• Additional information:

  • Participated in all lectures and lab sessions, actively contributing to project discussions and sprint planning.
  • I always filled my issues with information, even when I was not the one to create it. Because most of the time, we had boilerplate/placeholder issues that needed detailed instructions. I also made sure my issues were assigned to the project and had clear start-end dates #361
  • Collaborated closely with team members to go over frontend implementation and ensure quality standards.
  • Coordinated with backend developers through joint development efforts.

• Responsibilities: My primary responsibility this milestone was designing and implementing the Moderation System on the frontend. I was responsible for determining how the moderation workflow should function and translating that design into a working implementation. Additionally, I contributed to creating the implementation plan for the milestone, served as a bridge between the backend and frontend teams to ensure synchronization, and conducted extensive code reviews throughout the milestone. On the non-code side, I created the skeleton structure for the web demo scenario presentation.

• Main Contributions: My main contributions centered around the Moderation System implementation and bug fixes that ensured a stable release. For the Moderation System, I designed and implemented the report and report review functionality on the frontend, creating the user interface for submitting reports and the admin interface for reviewing and acting on those reports. I also resolved several bugs across the application: I fixed an issue where flash messages for actions like logging in, posting, and garden creation were not displaying after user actions but instead appeared only after logout on the login screen. I corrected CSS issues causing Forum Post titles to render incorrectly. I fixed a Task Board assignment bug where regular members could not assign unassigned tasks to themselves (while garden owners could assign tasks to anyone, regular members were incorrectly blocked from adopting unassigned tasks). I also fixed Badge visibility issues by correcting API requests that were being sent to incorrect endpoints.

• Significant Issues:

  • Code-Related:
    • Error/Success Messages Display (Issue #378, PR #386): Fixed a bug where flash messages for user actions (logging in, posting, garden creation, etc.) were not displaying after the action occurred. Instead, these messages would only appear after the user logged out and navigated to the login screen. I corrected the message display timing to show feedback immediately after user actions.
    • Moderation System Report-ReportReview (PR #413): Designed and implemented the complete moderation system frontend, including the report submission interface for users and the report review interface for administrators to manage and act on submitted reports.
    • Task Board Assignment Fix (PR #426): Fixed an issue where regular members could not assign unassigned tasks to themselves. The intended behavior is that anyone should be able to adopt an unassigned task, while only garden owners can reassign tasks that are already assigned to someone else.
    • Forum Post Title Issue (PR #432): Fixed CSS issues that were causing forum post titles to display incorrectly.
    • Badge Visibility Fix (PR #433): Corrected API requests that were being sent to incorrect endpoints, fixing badge visibility issues on the frontend.
  • Non-Code-Related:
    • Web Demo Scenario: Created the skeleton structure for the web demo scenario presentation, establishing the framework that the team used for the demo.
    • Implementation Planning: Contributed to creating the implementation plan for the milestone, helping coordinate work across the team.
    • Team Coordination: Acted as a bridge between backend and frontend teams, ensuring synchronization and smooth communication throughout the milestone.

• Pull Requests:

  • Created:
    • PR #386: Fixed error/success message display timing
    • PR #413: Implemented Moderation System Report-ReportReview
    • PR #426: Fixed task board assignment for unassigned tasks
    • PR #432: Fixed forum post title CSS issues
    • PR #433: Fixed badge visibility endpoint issues
  • Reviewed:
    • PR #410: Feature/frontend garden events
    • PR #397: Improve Frontend Unit Tests
    • PR #349: Feature/UI improvements
  • Conflicts: I encountered a minor conflict in the moderation system PR due to concurrent changes in shared components. Before opening the PR, I merged the dev branch into my working branch and resolved the conflicts locally to ensure a clean merge.

• Additional Information: I attended all lab sessions and actively participated in project discussions and sprint planning. I maintained regular communication with team members through WhatsApp to stay aligned on progress and blockers. I worked closely with frontend teammates to review implementations and maintain code quality, and coordinated with backend developers through collaborative development sessions to ensure seamless integration between frontend and backend components.