The Code Wasn't the Hardest Part. Understanding Why It Was Written Was.
Our Hacktoberfest Hack Day journey: exploring how AI can help developers recover forgotten decisions from open-source projects.
Imagine joining an open-source project with thousands of lines of code.
You explore the codebase, understand its structure and find something you think could be improved. You suggest replacing the existing database with another technology.
Then someone tells you:
"We already discussed this two years ago. We rejected that approach."
You ask why.
Nobody remembers the complete discussion. The original contributors may have left, and the reasoning is buried somewhere inside hundreds of GitHub comments.
You can still see the code. But you cannot easily understand the thinking behind it.
And that is the problem we wanted to explore.
The hidden problem in open source
Open-source projects are built through collaboration. Developers discuss features, review pull requests, report bugs and debate architectural decisions.
But something important often gets lost in this process: the reasoning behind decisions.
For example:
- Why did the team choose PostgreSQL instead of MongoDB?
- Why was a particular API design rejected?
- Why did maintainers decide against a proposed feature?
- Was an alternative already tested and found unsuitable?
These answers may exist in old GitHub Issues, Pull Requests and discussion threads, but finding them can take a lot of time.
This creates a knowledge gap for new contributors.
They may repeat old discussions, suggest approaches that were already rejected, or make changes without understanding the project's history.
The problem isn't that the information never existed. The problem is that it is difficult to recover when someone needs it.
Our idea: Recovering the knowledge behind the code
For Hacktoberfest Hack Day at Rishihood University, Sonipat, we explored Problem 6: Open Source Decision Intelligence and Knowledge Recovery.
Our goal is to design an AI-powered platform that helps developers discover the technical decisions hidden inside public project discussions.
Instead of simply summarizing GitHub conversations, we want the system to identify:
- The decision: What did the team decide?
- The reasoning: Why did they make that decision?
- Rejected alternatives: What other approaches were considered, and why were they rejected?
- The status: Was the decision accepted, rejected or still under discussion?
- The evidence: Where did this decision originally come from?
The last point is especially important. We don't want developers to blindly trust an AI-generated answer.
Every recovered decision should point back to its original discussion so that developers can verify it themselves.
How would it work?
Let's understand our proposed workflow with a simple example.
Suppose a developer wants to understand why a project uses PostgreSQL.
Step 1: Enter a GitHub repository
The developer provides the URL of a public GitHub repository.
Step 2: Collect project discussions
The platform retrieves relevant public Issues, Pull Requests and comments using the GitHub API.
Step 3: Extract technical decisions
An AI model analyzes the discussions and tries to identify decisions, their reasoning, alternatives and their status.
Step 4: Store structured knowledge
Instead of saving only a long summary, the system stores each decision in a structured format, along with its original discussion link.
Step 5: Search and recover
A developer can ask:
"Why did this project choose PostgreSQL?"
The platform should return the recovered decision, explain the reasoning and provide the original GitHub discussion.
This is the experience we want to build.
Why not just use a normal AI chatbot?
This was an important distinction in our thinking.
A general AI chatbot can explain PostgreSQL, MongoDB or database architecture. But that doesn't mean it knows why a particular open-source project made its decision.
Our platform has a different responsibility.
It should recover knowledge from the project's own history rather than generate a generic technical answer.
For us, a useful answer isn't just a convincing explanation.
A useful answer is one that can be traced back to evidence.
The technical thinking behind our approach
We are approaching this as a combination of full-stack development, information retrieval and AI.
Our planned architecture has four main parts:
- GitHub integration: Collect public project discussions and their references.
- AI decision extraction: Analyze conversations and identify decisions, reasons and rejected alternatives.
- Knowledge storage: Save extracted information in a structured format.
- Search interface: Allow developers to search and explore recovered decisions.
We also recognize that extracting decisions isn't as simple as summarizing text.
A discussion may contain several opinions before reaching a final conclusion. A suggestion might be rejected in one comment but accepted later in the same conversation.
The system must distinguish between a suggestion, a discussion and an actual decision.
It must also avoid inventing reasons when the original discussion doesn't provide enough evidence.
These are challenges we want to address rather than hide.
What would make this useful?
Imagine a new contributor opening a Pull Request that changes an important part of a codebase.
What if the project could surface relevant historical decisions associated with the files being changed?
The contributor could understand previous discussions before proposing a change.
This could help teams:
- Avoid repeating previously rejected approaches.
- Understand architectural decisions.
- Onboard new contributors faster.
- Preserve knowledge when experienced developers leave.
- Make changes with better awareness of project history.
Our longer-term direction is to connect recovered decisions with relevant source code and surface that knowledge when future Pull Requests modify related files.
What we want to learn from this Hack Day
This challenge is not just about integrating an AI API into a web application.
It pushes us to think about a deeper engineering problem: how do we turn unstructured conversations into reliable, searchable and verifiable knowledge?
We want to explore how AI can identify meaningful decisions, how to preserve their original context, and how to make the results useful to actual developers.
We also understand that the system will not always find a clear answer. Sometimes a discussion has no final decision. Sometimes the reasoning is incomplete.
In those situations, showing uncertainty is better than pretending to know.
Looking ahead
Our vision is simple:
When a developer asks, "Why was this done this way?", they shouldn't have to spend hours searching through years of project discussions.
They should be able to discover the decision, understand its reasoning and verify it from the original source.
Because software isn't just a collection of files and functions.
It is also a collection of decisions made by people over time.
Code tells us what a project does. Its history helps us understand why.
And we believe that recovering that history can make open source easier to understand, maintain and contribute to.
Built as a Hacktoberfest Hack Day project exploration at Rishihood University, Sonipat.
AI assistance was used to help organize and refine this article. The project concept and implementation details should reflect our team's actual work and decisions.
Top comments (0)