Collaborative Software Development Project¶
Learning Goals¶
- Translating requirements into actionable user stories
- Practice getting to know a pre-existing code base and developing new features for it using previously unfamiliar technology
- Practice version control and development best practices within the context of a group assignment
- Plan and schedule projects in terms of tasks, milestones, and time estimations, and re-plan as required
- Make initial decisions on a team process, and reflect on your experience with the process
- Effectively coordinate among team members and conduct team meetings
- Meaningfully reflect on the experience of working in teams
Project Context¶
Almost no software engineer spends their career writing new systems from scratch. The overwhelming majority of professional software work is joining something — a codebase with years of history, decisions you were not there for, conventions nobody wrote down, and a backlog longer than anyone will ever finish.
That is the experience this project is built around.
Your team has been assigned one of eight real open-source projects. These are not teaching examples. They are mature systems with real users, real maintainers, real test suites, and real technical debt.
The Eight Projects¶
| Project | Stack | What it is |
|---|---|---|
| Actual Budget | TypeScript, React | A local-first personal budgeting app. Your financial data stays on your own machine rather than on someone's server, with syncing between your devices as an option you switch on. The local-first design is the interesting part: much of the database work happens in the browser. |
| Excalidraw | TypeScript, React, Canvas | The hand-drawn-style virtual whiteboard you have probably used for a diagram at some point. Multiple people can draw on the same board at once, which makes it a real exercise in canvas rendering and keeping several clients in agreement. |
| Gitea | Go | A self-hosted Git service — repositories, issues, pull requests, CI — that a small team can run on one machine as an alternative to GitHub. The only Go project on the list, and the only one where you are working on the kind of tool you use every day in this course. |
| Medusa | TypeScript, NestJS, React | A headless commerce platform: the backend is one piece, the storefront and the admin dashboard are separate. Heavily modular, so a lot of the work is understanding how the pieces are meant to plug together before you add another one. |
| Chatwoot | Ruby on Rails, Vue.js | A customer support platform that pulls live chat, email, and social channels into one shared inbox. A conventional Rails application at heart, which makes it a good place to see how strongly a mature framework shapes the code written in it. |
| Discourse | Ruby on Rails, Ember.js | The forum software behind a great many online communities, including a lot of open-source projects' own support sites. The oldest and probably the most opinionated codebase here, with an extensive plugin architecture and correspondingly firm conventions. |
| Cal.diy | TypeScript | Open-source scheduling and booking — the "here is my calendar, pick a slot" problem, in the same space as Cal.com. Scheduling looks simple until time zones, recurring availability, and double-booking get involved. |
| Outline | TypeScript, Node, React | A team wiki and knowledge base with real-time collaborative editing. Collaborative rich-text editing is genuinely hard — two people typing in the same paragraph have to end up with the same document — and that machinery sits at the centre of this codebase. |
They differ in more than size. A Go server, two Rails applications, and five large
TypeScript codebases will not teach you the same lessons, and neither will their
communities: some document every convention in CONTRIBUTING.md, others expect you to
infer them by reading the code around you. Part of what you are being graded on is noticing
which kind you have landed in.
You and your teammates are joining that project as a new team of contributors. It is up to you to assess the current state of the codebase, work out what would genuinely be worth building, scope a set of user stories, and implement them — following the conventions the project already has, not the ones you would have chosen.
You are working in a course copy, not the real project
Your team's repository comes from UCF Code Classroom, and your team works entirely inside it. Do not open issues or pull requests against the upstream project, and do not ask upstream maintainers for help with coursework. Their time is a real resource and it is not ours to spend.
Start from the STUDENTS.md file in your repository root — it covers getting your
particular project installed and running.
Keeping up with the upstream project is your team's call
Your repository was snapshotted from the upstream project when it was provisioned, so over the semester the real project will move ahead of you — you may well see the running app tell you a newer release is available.
Pulling those upstream changes in is entirely optional. It is a reasonable thing to do and you are welcome to, but it is not required, nobody is graded on it, and a team that stays pinned to the baseline version is not at any disadvantage. If you do decide to merge upstream, do it deliberately and early in a sprint rather than in the days before a deadline — a large merge landing on top of in-flight feature branches is a bad week for everyone.
Expect this to feel disorienting at first. Finding the right five lines to change in a codebase of this size is most of the work, and it is a genuinely different skill from writing something new. That difficulty is the point of the assignment.
Deliverables and Deadlines¶
This will be the first assignment with your group. There are two (2) deadlines for this project. Each of the core deliverables is described below. This project is worth a total of 200 points.
Detailed information for each of the deadlines has been split into its own subpage on the left.
Tip
This is a large assignment spanning from now until shortly after the midterm. We estimate that this project will take each student on the team on average 8 hours/week, and we highly recommend reading through the entire assignment before starting so you are aware of our expectations for the later deliverables.
To manage all of the write-ups, we recommend saving the pages as a PDF to print or annotate on as you work through the assignment with your team.
A) Team Contract, Standards & Planning – 70 points – due Friday, September 25th, 11:59pm
- Prerequisite: Team Setup
- Teamwork Contract (20 pts)
- Standards & Guidelines Document (20 pts)
- Feature Backlog & Project Planning (25 pts)
- AI Tooling Setup (5 pts)
- Extra Credit (7 pts)
B) Development Sprint – 130 points – due Friday, October 23rd, 11:59pm
- Process & Implementation Project Snapshot (80 pts)
- Project Presentation (50 pts) - Short Video