Proof_Line

• 

  Members Details

• 

  Understanding_Tasks

• 

  Timeline

• 

  Dashboard

## Inspiration

In hackathons, university projects, and collaborative software development, the final result does not always show how much each team member contributed. Some members implement features, others fix bugs, review code, or work on specific files. Simply counting commits cannot fairly represent everyone's work.

I built Proof_Line to make individual contributions more transparent by connecting GitHub activity with assigned tasks and evaluating team members' understanding of their work.

What it does

Proof_Line analyzes GitHub repositories to help teams understand individual contributions through recorded development evidence.

It also helps professors evaluate group projects by organizing evidence across team members, allowing instructors to investigate individual participation without manually inspecting every commit and file in every repository.

Its main features include:

• GitHub activity analysis: Collects commits, pull requests, changed files, code additions and deletions, reviews, and review comments.
• Individual contribution insights: Organizes development activity by team member to show how each person participated.
• Task and file matching: Compares assigned tasks with relevant file changes to connect development evidence to planned work.
• Contribution analytics: Presents visual summaries of team activity and individual contributions.
• Understanding evaluation: Allows team members to answer questions about their work and evaluates their responses to provide additional insight into their understanding.
• Evidence-based reporting: Helps teams explore contribution patterns using actual repository activity rather than relying only on self-reported work.

Proof_Line is designed to support fairer evaluations, not to judge a person's value solely by the number of commits they make.

How I built it

I built Proof_Line as a full-stack application with a React frontend and a FastAPI backend.

The frontend provides the interface for managing projects, exploring team members, viewing contribution analytics, and completing understanding evaluations.

The backend connects to the GitHub API to retrieve repository information, commits, pull requests, changed files, reviews, and comments. I developed an analysis engine to organize this evidence by contributor and connect relevant file activity with assigned tasks.

I use structured evidence and analysis rules to generate contribution insights. The understanding evaluation workflow complements repository activity by examining team members' explanations of their work.

My goal was to build a tool where insights are grounded in observable development evidence rather than relying entirely on generic AI-generated assessments.

Challenges I ran into

One of my main challenges was accurately identifying contributors. GitHub usernames, commit authors, and repository contributors do not always correspond perfectly, so interpreting activity requires careful handling.

Another challenge was collecting and organizing different types of GitHub evidence. Commits, pull requests, reviews, and file changes provide different perspectives on development work, and combining them without double-counting activity requires thoughtful analysis.

I also faced the challenge of connecting technical activity to assigned tasks. A changed file does not automatically prove that a task was completed, and contribution volume alone does not measure code quality or understanding.

Finally, integrating the backend analysis with the frontend required handling API errors, session states, and different response formats while keeping the application clear and useful.

Accomplishments that I'm proud of

I'm proud to have built a full-stack application that approaches team contribution evaluation from an evidence-based perspective.

Some accomplishments I'm particularly proud of include:

• Integrating GitHub repository data into a structured contribution analysis workflow.
• Organizing development evidence around individual team members.
• Connecting task assignments with relevant repository file activity.
• Building visual analytics to make contribution patterns easier to understand.
• Creating an understanding evaluation workflow that complements GitHub activity.
• Developing a project that addresses a real challenge in hackathons, student projects, and collaborative software development.

Most importantly, I moved beyond a simple commit counter toward a more complete picture of how team members participate in a project.

What I learned

I learned that measuring software contributions is more complex than counting commits or lines of code. Different team members contribute in different ways, and meaningful evaluation requires context.

I also learned how challenging it can be to work with real-world GitHub data, handle API limitations, associate activity with the correct contributors, and design an analysis pipeline that produces useful insights.

Building Proof_Line helped me improve my skills in full-stack development, API integration, data processing, evidence-based analysis, and designing tools around real user problems.

I also learned the importance of transparency: contribution insights should be explainable, grounded in evidence, and presented with their limitations rather than treated as definitive judgments.

What's next for Proof_Line

I plan to improve Proof_Line by making its analysis more accurate, transparent, and useful for different types of teams.

My next steps include:

• Improving contributor identification and handling different GitHub author identities.
• Refining task-to-file matching and providing clearer evidence for each finding.
• Expanding contribution analytics to better represent reviews, collaboration, and less visible work.
• Improving the understanding evaluation workflow and its feedback.
• Adding clearer explanations of how contribution insights are calculated.
• Testing with more repositories and teams to identify limitations and improve reliability.

My long-term vision is to help teams understand not just what they built, but how each member contributed to building it.

Built With

• fastapi
• github
• httpx
• javascript
• llm
• python
• react
• sqlalchemy
• sqlite
• tailwinds
• vite