After building and operating a system for a college event, I learned that it had been presented without acknowledging my work. I opened the repository. The commit history was still there, but the people hearing about the project had not seen that history.
I had expected an auditable record to produce accurate recognition. The experience exposed a missing step: someone still had to connect the record to the account of the project.
That distinction matters beyond a disagreement over credit. Teams need to know who understands a system, why a decision was made, and whom to involve when requirements change.
A repository records a subset of the work
Code history can help explain how an implementation changed. It does not capture every conversation, discarded approach, design review, or operational responsibility.
Even the tools have narrower meanings than their names suggest. git blame identifies the revision and author that last modified a line. That information does not establish who proposed the feature or designed the system.
A large commit can include mechanical changes. A small review comment can prevent a serious defect. A contributor may spend hours diagnosing a failure and leave only a one-line fix.
Commit counts therefore make a poor substitute for a contribution record. They measure repository activity while leaving much of the engineering work outside the frame.
Describe roles with precise verbs
The phrase “I built this” is convenient, but it can conceal several different claims. A project can have separate contributors for the idea, implementation, release, and operation.
These descriptions give a reader more useful information:
| Contribution | A record that helps explain it |
|---|---|
| Proposed the approach | A dated proposal with the problem and alternatives |
| Designed the system | A decision note with constraints and tradeoffs |
| Implemented a component | Relevant commits and reviewed pull requests |
| Validated behavior | Test results, review notes, and reported defects |
| Released and operated it | Release records and incident follow-up |
None of these records is complete proof by itself. Together, they make an account easier to assess and help contributors describe their work accurately.
The same precision should apply to my own claims. If I implemented one part, I should name that part. If another person reviewed the design or operated the deployment, their work belongs in the account too.
Make the project history easy to find
The useful response is to create a small record while the facts remain clear. A project page or release note can answer six questions:
- What problem did the project address?
- When did the work occur?
- Who contributed, and what did each person do?
- Which constraints shaped the design?
- What was delivered?
- Which evidence supports the reported result?
Link that record from the README and demo when appropriate. For a private project, keep it with the team's internal documentation. Public evidence does not require publishing confidential code or client information.
A result also needs a definition. “Handled 20,000 operations” is difficult to assess without the operation type, measurement period, and source. Describing those details gives the work substance and prevents a vague metric from carrying more meaning than it supports.
The goal is to make a short project account accurate enough that someone else can repeat it without erasing its contributors.
Communication is part of engineering work
An engineer who explains a system clearly helps the team review decisions and maintain it. Demos and concise project summaries are useful work.
The attribution problem appears when an explanation omits the people responsible for the result. A polished presentation should make their contributions easier to understand.
Section 1.5 of the ACM Code of Ethics calls for credit to the creators of ideas, work, and computing artifacts. In practice, that means naming contributors when presenting their work and correcting material omissions.
That principle applies in both directions. I want my work represented accurately, and I owe others the same care when I present a shared project.
Address a disagreement with a specific record
When accounts differ, separate what the evidence establishes from what remains disputed. A release record can support a delivery date. It may not establish the origin of every idea discussed before implementation.
A useful correction identifies the missing contribution, links the relevant evidence, and names the statement that needs clarification. Claims about another person's motives are harder to establish and rarely make the record clearer.
If a direct conversation does not resolve the issue, a project lead or faculty supervisor can review the material. The record should help that person assess the facts without requiring them to reconstruct the entire repository.
What I will document with the next release
I left too much of my project's history implicit. The code recorded changes, while the broader account of the work remained scattered across conversations and memory.
For the next release, I want a concise project note alongside the implementation: the problem, decisions, contributors, and evidence of the result. That record will help future maintainers as well as people assessing the work.
Fair attribution becomes easier when a project explains how it came to exist. Writing that explanation is part of taking responsibility for the system and the people who helped create it.
