This lab is not about REST, Express, or Node.js.
This lab exists to make collaboration and ownership visible.
You will work as a team to evolve a small codebase under mild ambiguity, while making your decisions, communication, and responsibility observable through your workflow.
This lab focuses on:
- How teams divide and own work
- How ownership is expressed through Git
- How teams collaborate through pull requests and reviews
- How teams respond to change
- How responsibility persists beyond “my part is done”
Code correctness is secondary. Behavior and process matter most.
- This is a team lab
- This is a throwaway exercise
- The code produced here will not be used in your semester project
- You are expected to use:
- Feature branches
- Pull requests
- Code reviews
- Direct commits to
main - One person implementing everything
- “LGTM” reviews with no substance
One member of your team must:
- Fork this repository into your team’s GitHub account
- Add all teammates as collaborators on the fork
- Ensure everyone can push branches and open pull requests
All work for this lab must occur in your team’s fork.
You are given a very small Express application with a single entry point: src/index.js
The application already:
- Starts an HTTP server
- Parses JSON request bodies
- Exposes a root route
You may add code above the marked boundary only.
Your team is responsible for evolving this service to support a basic user lifecycle.
At a minimum, the service should allow:
- Creating users
- Retrieving users
- Updating users
- Deleting users
User data may be stored in memory.
The exact API design, data structures, and implementation details are up to your team.
There is no single “correct” solution.
Before writing any code, your team must agree on:
- Who owns which parts of the system
- Who is responsible for integration
- How decisions will be made
- How disagreements will be resolved
Create a file named: OWNERSHIP.md
This file should briefly describe:
- What each person owns
- How ownership will be enforced
This document is not graded for quality — only for clarity and intent.
As you implement:
- All meaningful changes must be made on branches
- All branches must be merged via pull requests
- Every pull request must receive at least one real review
- Review comments should be specific and constructive
Commits should represent complete, coherent changes, not experiments.
Partway through the lab, a requirement or assumption may change.
This is intentional.
What matters is:
- How quickly the team notices
- How ownership adapts
- How communication changes
No additional time will be given.
By the end of the lab:
mainshould be in a working state- There should be evidence of:
- Multiple contributors
- Pull requests
- Reviews
- Discussion
- Open issues or TODOs are acceptable if clearly communicated
This lab is evaluated on process, not polish.
Positive signals:
- Clear ownership
- Visible collaboration
- Meaningful reviews
- Adaptation to change
- Professional communication
Negative signals:
- One person doing all the work
- No reviews
- Silent disagreement
- Direct commits to
main
You are not given a point-based rubric for this lab.
At the end of the lab, one team member must:
- Post the URL of your team’s repository fork to the #labs Discord channel
- Ensure the repository shows:
- Branches
- Pull requests
- Reviews
- Multiple contributors
No additional write-up is required.
In professional software teams:
- Ownership is observable
- Collaboration leaves artifacts
- Silence is a signal
This lab is designed to surface those realities early.
Treat it accordingly.