Home

Welcome to the Quack-Campus-Event-Coordinator wiki!

Project Overview

Quack! is a campus-focused web application that helps students discover and organize informal, low-commitment meetups.

Project vision

A registered student can place an event pin on a campus map, add a date, time, location, and short description, and make the event open to everyone or accessible only through a link. Other students can discover nearby events, view details and attendance, and join or leave an event. Hosts can edit or cancel their events and review basic view and participation counts.

Project Scope

The semester MVP will deliver the complete account, post, discover, and join workflow for one campus on one client platform. The application will use persistent accounts and event data, map-based discovery, access-control rules, date filtering for past and upcoming events, and basic host controls. Profiles, interests, and personal invitations may be included after the core workflow is stable. Messaging, payments, ticketing, recurring events, and a full moderation dashboard are outside the initial scope. The final result will be deployed, tested, and demonstrated with realistic campus event data.

Roles

• Project Lead: Andre
• Project Manager: Andre
• Architect / Tech lead: Zhong
• Developers: Zhong
• DevOps / Automation: Zhong
• Test Engineer: Pratiksha
• UX Designer: Andre
• Requirements Engineer: Pratiksha

Project Risks

• Authentication integration: Google OAuth configuration or Stevens account restrictions may take longer than expected.
• Map-service dependency: The application depends on Mapbox availability, API limits, and correct token configuration.
• Location-data accuracy: Campus building names and pin locations may be incomplete or inaccurate.
• Schedule risk: The four-person team has one semester to design, implement, test, and deploy the application.
• Technology-learning curve: Team members may need time to learn Spring Boot, PostGIS, Mapbox, or deployment tools.
• Free-tier hosting limitations: Free hosting may introduce cold starts, resource limits, or service interruptions during the demonstration.
• Scope growth: Additional ideas such as messaging, notifications, recommendations, and moderation could delay the core workflow.
• Privacy and security: Authentication data, event visibility, and user location information must be handled carefully.

Assumptions

• Users have an active Stevens-managed account with a stevens.edu email address.
• Users have internet access and a modern mobile or desktop browser.
• Mapbox will remain available within its applicable usage limits during development and demonstration.
• The application will initially support one campus: Stevens Institute of Technology.
• Users will manually provide a location label when creating an event.
• Real-time updates are not required; refreshing or periodically retrieving data is acceptable.
• One application instance and one PostgreSQL/PostGIS database are sufficient for the semester project.
• The final demonstration will use seeded data and at least two valid test accounts.
• Messaging, payments, ticketing, recurring events, and a complete moderation dashboard are outside the semester MVP.