Gage‐Reflection

Contribution Summary – Gage B.

A. Inventory of Work

Role

Repository Manager & Workflow Coordinator

My involvement was focused on repository organization, issue creation, task documentation, deployment coordination, and merging feature changes submitted by teammates.

Though I did not write feature code, I facilitated the entire development path from idea → issue → implementation → review → merge → deployment.

Issues Authored or Managed

Below is a list of issues I opened, organized, or monitored:

Pull Requests Reviewed or Coordinated

https://github.com/gageb3/JobSeekers/pull/63
https://github.com/gageb3/JobSeekers/pull/61
https://github.com/gageb3/JobSeekers/pull/53
https://github.com/gageb3/JobSeekers/pull/49
https://github.com/gageb3/JobSeekers/pull/48
https://github.com/gageb3/JobSeekers/pull/38
https://github.com/gageb3/JobSeekers/pull/36
https://github.com/gageb3/JobSeekers/pull/29
https://github.com/gageb3/JobSeekers/pull/14

Brief Commentary

A large portion of my contribution is not directly visible through code commits. My main impact was ensuring project flow and accountability:

I created the majority of the task backlog and ensured every feature had a defined issue before implementation.
I communicated priorities between members.
I verified that changes were reviewed before merging into main.
I coordinated development meetings and tracked progress between work sessions.
I managed documentation, especially via patch branches specifically created to update the README.

This made sure that as teammates worked on features, the overall direction of the project stayed organized, tracked, and properly maintained within the repository.

B. What Worked Well for the Team (Management & Process)

Our most effective structure was meeting twice weekly (Tuesdays and Thursdays). These acted as informal standup meetings where we:

reviewed progress since the previous meeting
confirmed what was actively being worked on
reassigned or clarified issues where needed

A specific example:

When the database connection initially failed on deployment, we used a meeting to identify the issue (hardcoded connection strings). I documented this as an issue, we handed it off to a developer, and progress resumed without confusion. This prevented multiple people from accidentally working on the same fix.

Our communication channels were:

Discord (announcements, links, reminders)
In-person meetings (problem-solving, demonstrations)
GitHub (truth-of-record, documented work)

This combination worked because decisions that needed clarity happened in person, and decisions requiring documentation lived in github.

C. What Could Improve

An area that could have improved was documenting features earlier. Many ideas were discussed but not written down immediately, which caused delays and confusion later. If we had defined features and acceptance criteria sooner, we could have reduced rework and made expectations clearer from the start. Additionally, deployment and staging were implemented late, which limited early testing opportunities. Setting up deployment and review standards earlier would have allowed us to iterate faster and avoid last-minute fixes.

D. Technical Description of the Application (System Design)

Our system followed a basic full-stack architecture.

Backend

Built using Node.js with Express (a backend web framework).
Responsibilities:

routing requests
processing user actions
interacting with the database
storing login session data

Express acted as the controller layer of our system.

Database

We used MongoDB Atlas, a cloud-hosted NoSQL document database.

Each job application was stored as a document with fields such as:

company
position
date applied
status

We used .env variables to store our connection string securely.

Frontend

Rendered server-side using Express views and delivered as standard HTML/CSS/JS forms.

Users could:

add job applications
edit existing records
track status changes

Hosting & Deployment

Deployment occurred through Render, which automatically deployed whenever changes were merged into main.

The workflow was:

Develop in dev → review changes → merge to main → Render deploys

This provided a single source of truth for production.

Branch Structure

Branch	Purpose
`main`	Live production version
`dev`	Active development branch
`patch` branches	Documentation-only changes

By separating documentation into patch branches, README updates did not interfere with development code.

E. Advice to Future Students

I would recommend:

Start documenting on day one

Documentation at the end feels rushed and incomplete.

Defining issues clearly saves time later because people do not need repeated clarification.

Establish merging rules immediately

Require approval before merging into production.

Deploy early

Even a half-working prototype deployed early:

exposes environment issues sooner
forces clarity on DB connection configuration
reveals real-world behavior

Use issues as the project source of truth

When questions arise later (e.g., why was this changed?), documented issue history answers it.

If I could tell my past self one thing:

“Treat your GitHub project board as your syllabus checklist. If it’s not written there, it won’t get tracked correctly.”

This would have reduced last-minute confusion, especially during final deployment.

Navigation Menu

Gage‐Reflection

Contribution Summary – Gage B.

A. Inventory of Work

Role

Issues Authored or Managed

Pull Requests Reviewed or Coordinated

Brief Commentary

B. What Worked Well for the Team (Management & Process)

C. What Could Improve

D. Technical Description of the Application (System Design)

Backend

Database

Frontend

Hosting & Deployment

Branch Structure

E. Advice to Future Students

Start documenting on day one

Establish merging rules immediately

Deploy early

Use issues as the project source of truth

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Clone this wiki locally