Maintainer guide · learned in production
What it means to win a cohort repo
Winning is great, but it also turns your project into shared infrastructure. The moment your app becomes the cohort default, you are no longer just shipping features — you are maintaining a live platform while other people, and often their coding agents, start contributing to it too.
Based on lessons from Calvin Trinh’s Project 1 winning repo, Forth, for the Curious Boston × Hult International School AI Engineering cohort.
Heads up: even with a CONTRIBUTING guide, a ticket backlog, and a clear claim process, some contributors still skipped instructions, opened overlapping pull requests, or submitted work without passing checks. Future winners should plan for that coordination burden up front.
The operating reality after a win
Treat the winning repo like a real product, not a class artifact. Keep one clear roadmap, protect production settings, and make sure maintainers decide what gets merged. A winner repo stops being “just your project” very quickly.
Force scope clarity before people start coding. If contributors do not claim a ticket and wait for confirmation, you will spend your time merging duplicate work or unwinding conflicting assumptions instead of improving the product.
Make quality gates visible and non-negotiable. State in writing that CI, testing, screenshots, and accessibility checks are part of the contribution itself. That saves the maintainer from debating basics in every PR.
Assume AI agents need operating instructions too. If humans may skip repo instructions, their agents definitely will unless you put the workflow in AGENTS.md, CONTRIBUTING.md, and a public handoff doc the agent can read before editing.
Example contribution system that helped
Forth eventually stabilized by making the contribution workflow explicit for both humans and coding agents. The repo used a claim-first process, a public backlog, a shared handoff document, and protected areas that needed maintainer approval.
- Example rule
Read README.md, AGENTS.md, docs/AGENT_HANDOFF.md, and docs/ticket-backlog.md before touching code.- Example rule
Open a ticket claim, link the backlog ticket, describe your proposed slice, and wait for explicit scope confirmation.- Example rule
Branch from the agreed base, keep the change focused, run the required checks, and open a draft PR early.- Example rule
Do not deploy, alter production services, rotate credentials, or migrate real data.
Those rules reduced chaos, but did not eliminate it. That is the main lesson: writing a process helps, but maintainers still need permission to reject duplicate, unscoped, or failing work without guilt.
How to think about it
- Plain-language takeaway
- Winning means you need a traffic system, not just a codebase. You need people to know where to enter, what lane they own, and what rules keep everyone from crashing into each other.
- Engineering term
- This is a contributor-governance and change-management problem. Strong repos need documented intake, protected areas, scoped branches, CI gates, and explicit maintainer authority.
Suggested program guidance for future winners
- Publish a visible “what winning means” page so future winners know the hidden maintenance cost before they volunteer.
- Score contribution quality partly on whether contributors followed the repo workflow, even if the final code is not merged.
- Encourage cohorts to claim scope first and reward good coordination, not just raw PR count.
- Treat maintainers as product owners with the right to decline overlapping or low-signal work quickly.