Built with React 18, React Router 6, and a Bootstrap-based theme, the web client delivers all user-facing pages (Main, Tips, Challenges, Community, Profile) while enforcing access control through ProtectedUserRoute and ProtectedAdminRoute. The front end has all the elegant pages with a responsive design.

Powered by Django 4, Django REST Framework, MySQL, and JWT (SimpleJWT), the API handles authentication, user profiles, posts, comments, waste tracking, tips, and admin moderation; immediate tasks include finalizing Post/Like/Comment endpoints,image storage, and using Django's built-in unit test commands.

Implemented in React Native CLI with Context-based auth and React Navigation, the mobile app mirrors core web flows across Home, Challenge, Community, Profile, Login, and Signup screens, syncing via the same API; focus is on binding live data to Challenge/Community screens.

Deliverable	Status (✅/⚠️/❌)	Link / Evidence
Repository setup	✅	GitHub Repo
Requirements document	✅	SRS Document
Design diagrams	✅	Use Case Diagram
Implementation (MVP)	✅	MVP Link
Test suite & CI	⚠️	-
Documentation / Wiki	✅	Wiki Page

Our complete issue conventions template can be seen here. In short, we write the problem description, recreation steps if it is a bug, testing steps if it is a feature, and write the deadline for the issue to ensure timely completion and track if there is a problem in the progress, so we can assign more people if the deadline is coming and not enough progress is done yet. Our labels include the priority and expected time the issue will take. We believe these create a great overall template, and served us good in tracking the progress of our tasks.

We considered two primary options for our meeting cadence:

1. Weekly fixed meetings: Regular meetings scheduled at a consistent day and time each week.
2. Flexible weekly meetings: Meetings scheduled dynamically based on team availability and immediate project needs, while ensuring at least one meeting occurs per week without exception.

After careful consideration, we chose flexible weekly meetings. Our rationale was informed by our experiences in previous terms, where workloads fluctuated significantly—some days requiring intense collaborative focus, while others were comparatively lighter. A flexible schedule would in theory allow us to adapt effectively to these varying demands, mitigating situations where multiple people would be unable to attend because of a tight deadline. To ensure consistency and maintain regular communication, we strictly enforced the rule of having at least one meeting per week, no matter if the week was relatively light or intense.

Overall, we think this decision helped in times of unprecedented events we lived through this semester, and we never had the problem of being unable to find a time slot that was inconvenient for all members. Even though we had attendance problems in some meetings, it is highly unclear if a fixed meeting schedule would help with this problem, since this is a problem that occurs in every group at some point. All things considered, we can say that this was a good decision for the requirements of this semester.

As part of our software development process, our team has agreed on a structured approach to maintaining and updating the project’s wiki page to ensure clarity, consistency, and ease of access.

Documentation Structure:
We decided to organize the wiki using a modular structure. The main sections include:

• Project Overview: Summary of the project's purpose, features, and scope.
• Installation & Setup Guide: Step-by-step instructions for setting up the development environment and running the project.
• Architecture & Design: Diagrams and descriptions of key modules, data flow, and design decisions.
• API Documentation: Description of endpoints and request/response formats (will be auto-generated where possible).
• Development Guidelines: Team coding conventions, branch naming rules, and commit message format.

Update Policy:
Documentation updates are treated as part of each feature’s Definition of Done. A pull request is not considered complete unless the relevant wiki sections are updated accordingly.

By committing to maintain up-to-date documentation throughout the project, we aim to facilitate collaboration, onboarding of new members, and future maintenance.

---

Milestone	Start → End	Owner(s)	Status
Milestone 1: Login and Sign up functionalities	2025-04-16 → 2025-04-25	All	✅
Milestone 2: All other functionalites	2025-05-05 → 2025-05-15	All	✅
Final Milestone Report	2025-05-10 → 2025-05-17	All	✅

---

Team Member	Core Contributions*	Evidence (PRs / lines / issues / docs)
Eren Akçin	- Set up the cloud instance. I was responsible for all DevOps-related jobs, like containerization and deployment of the backend. I prepared the hall cloud environment before the backend team began working on it. I created deployment scripts and ran Jenkins in a Docker container for CI/CD automation. Additionally, I was responsible for developing the hall profile backend API. I created the required backend structure for use in profile-related tasks. I reviewed and merged multiple PRs. Additionally, I believe I made a significant contribution to determining the main structure of the backend. I was also a major contributor to the process of creating use cases and sequence diagrams with @basartemiz. Finally, I actively participated in the elicitation and preparation of the requirements.	PRs: [#195] Commits: All commits on 23 April, just before the team starts the development. Issues: https://github.com/bounswe/bounswe2025group10/issues?q=is%3Aissue%20state%3Aclosed%20author%3Aakcineren
Mustafa Ocak	- Set up the base structure and testing environment for the mobile app. - Developed Home, Login/Signup, and Community pages with core functionality and authentication. - Implemented bottom tab navigator and handled overall mobile navigation. - Initialized the Challenges Screen implementation and handled core backend / API relations. - Took most meeting notes, acted as task distributor, and served as mobile team's representative.	PRs: 13 Total Issues: 45 total Diagrams: Issues #52, #55, #80
Samed Kızılhan	- Implemented Main Page and Leaderboard pages with their all functionalities. Contributions in completing SRS.	Issues, PR
Başar Temiz	- Architected and delivered the modular Admin Panel, User Panel, and Comment Panel for streamlined content and user management. - Built a dynamic Profile Page featuring avatar upload, bio editing, and real-time persistence. - Implemented secure Login / Sign-Up logic with JWT-based authentication and client-side form validation. - Produced UML artifacts: an interactive One-Second Diagram, detailed Use-Case Diagram, and a Combined Use-Case Diagram unifying multiple scenarios. - Led a 10-member team, organizing meetings, assigning tasks, and ensuring on-time delivery through clear milestones and regular stand-ups.	PRs: #87, #120, #136 Docs (sequence diagrams): https://github.com/bounswe/bounswe2025group10/issues/92
Umut Şendağ	- Created the base structure of the project and folders: initialized a Django repo with modular apps (authentication, waste, tips, posts, leaderboard), a shared core/ module for common utilities, and a config/ directory for settings, routing, and deployment setup. - Created the API’s for login-signup, Waste Submission and Retrieval, Tips, Posts and Comments, Leaderboard Page: implemented each service with JWT-based authentication, data validation, role-based permissions, CRUD operations, and paginated histories. - Used the external API Climatiq to calculate user scores for leaderboard: fetched CO₂ emission factors for materials.	PRs: PR Page Issues: Issue Page
Ceyda İrem Irwin	- Took an active role in both the mobile app development and documentation efforts. - Implemented major parts of the Challenges Screen in the mobile application, including functionality to view personal challenges, create new challenges, contribute to challenges by logging waste entries, and visual indicators for completed challenges. - Worked on Dockerizing the React Native development environment, enabling smoother collaboration and easier onboarding for mobile development. - Completed several research tasks, including learning React Native basics, working with Dockerized environments.	Issues: here Diagrams: #96 #59 #49
Bora Toprak Temir	- Designed and ER diagram for the database requirements and implemented the structure as Django Models. - Created the API for "Report System", where the users are able to report any media, and set up the database to allow such interactions flexibly in a maintainable way. - Created the API for "Admin Panel", where the admins are shown reported media and are asked to act on it (like banning the media or the sharing user). - Updated and fixed some problems with the challenge creation and progress feature when it was urgent for the bug to be fixed for frontends testing. The challenge progress was not updating correctly before the fix, and progress was allowed to go beyong 100 without the challenge completing. I also wrote challenge completion and automatic achievement awarding features along with it. - Written the "trivia questions" API using an external API that gives a trivia common question with multiple choices. This was planned to be displayed on the main page. - Created the mock data creation script, which creates realistic data for testing and demonstration purposes, including relations and interactions between every different media type. Created through the actual data processing pipeline to make sure it reflects the project's response to incoming data. - Written unit tests for all features that I implemented, adn executed comprehensive integration tests by testing through frontend and using postman for critical features to ensure no error. - Helped solve critical issues that was throttling development multiple times.	PRs: here PR Reviews: #130, #135, #139, #155, #183, #190, #194... and more Issues Completed: here Issues Written: here Wiki pages:    Personal Efforts: Data Creation Guide, Development Teams, Database ER Diagram, Wiki Contribution Guide ,Meeting 6 Notes, Meeting 7 Notes, Meeting 8 Notes, Requirements Meeting Notes, Backend Meeting 1 Notes, Entry to Cloud Database    Collaborative Efforts: API Documentation, Issue Conventions Software Requirements Specifications, Meeting 9 Notes Milestone Report
Berkay Ak	- Helped setting up the mobile development environment. - Handled Profile,Other's Profile Pages individually and helped Communication, Challenges and Home Pages in mobile. - Used an External API to show the current temperature in Home Page. - Helped in documentation both in planning part and in implementation part. - Researched about several topics including Git, Github, React Native and Docker.	Issues: Issues PR's: PR's
Cenk Yilmaz	- Coordinated and implemented the full front-end refactor for the Zero-Waste app, including the navigation navbar. - Led feature delivery for the Achievements, Challenges, Community, Profile, Posts, Comments, and Tips pages. - Ensured complete API integration by replacing all mock data with live backend endpoints. - Implemented key features such as: - Reporting system for posts and comments - Like/dislike reactions - Sorting and filtering of content - Wrote unit tests for all major components and user interactions to ensure stability. - Reviewed multiple pull requests to maintain code quality and consistency across the codebase.	PRs: PRs PR Reviews: PR reviews Issues: Issues
Mert Kirman	- Prepared comprehensive elicitation questions in order to determine boundaries and specifics of the project and also held a meeting with the teaching assistant going over each question. - Designed and implemented the Challenges API, enabling users to create, update, delete, and view challenges with appropriate permission checks for public and private challenges. - Developed the Challenge Participation feature, allowing users to join public challenges or their own private challenges while enforcing restrictions to prevent duplicate participation or unauthorized access to private challenges. - Created the Enrolled Challenges endpoint, which lists all challenges a user is currently participating in, providing a personalized view of their active engagements. - Integrated the Waste Logging feature with Challenges, ensuring that the current_progress of Challenges is automatically updated when users log waste, using atomic updates to maintain data consistency. - Wrote comprehensive unit tests to validate the functionality of the Challenges API, participation logic, waste logging integration, and permission handling, ensuring robust and error-free implementation. - Documented all implemented endpoints in the project wiki, including detailed descriptions, request/response formats, permissions, and usage examples for easy reference and collaboration. - Reviewed teammates' pull requests, providing constructive feedback to ensure code quality, adherence to project standards, and proper functionality.	PRs: Here PR Reviews: Here Issues Completed: Here Issues Written: Here Wiki Pages: Elicitation Questions (Original page on wiki got deleted and recreated for some reason, adding the github issue as proof), Git Documentation Contribution, Meeting 5 Notes, Challenges API Documentation

* Only list contributions that can be verified directly in the repository or project board. Use deep-links to specific lines when citing code.

---

• Tech Stack & Build:
  Built with React, Vite, and JavaScript, emphasizing speed and modularity.

  • ✅ What Worked: Vite’s lightning-fast hot module replacement (HMR) ensured iteration cycles stayed under 1 second, greatly boosting development efficiency.

• Testing:
  Adopted Vitest in combination with React Testing Library for a robust and fast unit testing experience.

  • ✅ What Worked: The test suite caught UI regressions early with minimal overhead, thanks to Vitest’s speed and JSX-friendly syntax that aligned well with React component testing.

• CI / CD:
  Integrated GitHub Actions for continuous integration and Vercel for preview deployments.

  • ✅ What Worked: Every pull request triggered automatic preview URLs via Vercel, enabling real-time design reviews and seamless stakeholder feedback.
  • 🌐 These previews gave each team member direct access to a live environment without local setup, accelerating collaboration and QA cycles.

• Early Mocking Unlocks Progress:
  By mocking endpoints early, the front-end team was not blocked by back-end delays and was able to deliver faster UI prototypes.

• Standardized Configuration Matters:
  Shared config (especially vite.config.js) across branches is essential to prevent hard-to-debug mismatches between development environments.

• Contract-First Communication Pays Off:
  Frequent coordination with the back-end team to ensure data contract alignment reduced bugs and integration rework.

• Previews Make a Big Difference:
  Automatic Vercel preview URLs enabled async feedback from non-technical team members, improving design iteration and team member communication.

• Tech Stack & Frameworks: Django + Django REST Framework

  • What Worked: DRF serializers simplified the creation of the views and made development easier.
  • Pain Points: 1. Adjusting the framework to use MySQL was challenging made some issues on for example already created tables or tables that are not created. 2. As we had more features that were implemented in the code, many serializers or views being in one view.py file and one serializers.py file made development harder since checking older code while we were testing or developing other features became challengin. 3. While we were connecting the backend with frontent, our frontend had an https: url but our server had an http: url. So we were unable to get requests from the frontend.
  • Action Items: 1. At first we were using MySQL scripts to create the tables. However when we were doing migrations it caused some problems. So we used those tables in the .sql files as guidelines and implemented our views and classes on the models.py file.
    2. We divided each feature to its own folders so finding what we were looking for became easier. 3. We had to get an SSL certificate to our backend server using sslip.io.

• Testing: Unit tests

  • What Worked: Django's already built unit test command (python manage.py migrate) reduced the burden on us while testing.
  • Pain Points: Django's test command were creating a separate test database. While it was creating it, it were clashing with MySQL's database (We actually had this issue at the same time while we were having the issue about MySQL mentioned earlier).
  • Action Items: .The fix of using models.py rather than .sql scripts fixed this problem.

• CI / CD: GitHub Actions → Server → Docker

  • What Worked: We created a .sh script called deploy.sh which first removes the containers and rebuilds everything related to the project in out server and docker.
  • Pain Points: 1. Every time we called that .sh script, our database would get erased and this is not something we wanted to happen everytime. 2. We didn't have data to be able to manually test if everything works fine.
  • Action Items:
    1. We created another script called deploy_save_db.sh and renamed the older one to deploy_destroy.db.sh, so that we can use any of them whenever we want.
    2. We created a create_mock_data command for Django's manage.py command so that we can automatically create mock data whenever we want to.

• Lessons Learned:

  • Use Django’s migration system as the single source of truth for your schema—manual SQL scripts breed conflicts and maintenance overhead.

  • Split serializers and view modules by feature as soon as you hit three endpoints per file; keeping one “thing” per file makes tracing bugs and adding features far easier.

  • Always align your backend’s protocol (HTTP vs HTTPS) with the frontend from day one—SSL mis-matches can stall integration for days.

  • Automate mock-data seeding early (“create_mock_data”) so your QA, staging, and CI pipelines never go without realistic test records.

  • Distinguish between destructive and safe deploy scripts (e.g. deploy_destroy_db.sh vs deploy_save_db.sh) to avoid surprise data wipes in production.

  • Cache external API lookups (Climatiq factors) to boost performance, reduce external dependency failures, and stay within rate limits.

  • Modular folder layout and feature-bound apps pay dividends when scaling: onboarding, code reviews, and parallel development all become smoother.

---

• Tech Stack & Frameworks: React Native CLI with TypeScript

  • What Worked: Leveraging TypeScript significantly accelerated the development cycle, enabling rapid prototyping and easier debugging.
  • Challenges: Working directly with bare React Native presented numerous configuration issues and led to time-consuming debugging sessions.
  • Lessons Learned: Modern frameworks when paired with TypeScript, greatly enhance developer experience and productivity. Choosing the right abstraction layer can prevent many common pitfalls.

• Testing: TypeScript-based unit and component tests, supported by extensive mocking

  • What Worked: Mocking key components and APIs helped isolate functionality and improved test reliability. TypeScript made the testing code more robust and readable.
  • Challenges: Writing and maintaining component tests was difficult, especially when dealing with CORS issues and complex component interactions.
  • Lessons Learned: Maintain close collaboration with the backend team to avoid integration surprises. Simpler test setups are often more maintainable and effective, particularly in the early stages of development.

• CI / CD Workflow: Emulator testing → Visual verification → Automated tests → Peer review & merge

  • What Worked: Manual testing on emulators was invaluable for catching layout and flow issues early. Visual verification helped ensure usability across devices.
  • Challenges: Automated tests (especially component-level) often failed to provide meaningful insights during debugging, leading to wasted time.
  • Lessons Learned: For straightforward features, prioritize emulator testing and manual validation over complex automated tests. Strike a balance between automation and pragmatism to maximize efficiency.