From GitHub Contributions to a Public Knowledge Graph: What We're Building with MyZubster
How we connected independent contributors, public development evidence, Knowledge Cards, and an interactive graph — and what we learned along the way.
By Daniel Ioni | MyZubster | October 2026
Topics: Open Source, JavaScript, Node.js, GitHub, Knowledge Graphs, Developer Tools, AI
What if a GitHub contribution could become reusable knowledge?
A pull request contains more than code.
It can represent hours of debugging, architectural decisions, technical research, new testing methods, and practical experience. Yet much of that knowledge remains scattered across repositories, commits, discussions, and documentation.
At MyZubster, we have been experimenting with a system that connects these different sources without losing their original context.
Our idea is relatively simple:
Every documented contribution should have the opportunity to become part of a discoverable knowledge network.
Instead of automatically converting repository activity into claims about someone's abilities, we want to preserve the original evidence and give contributors the option to build their own knowledge records around it.
This experiment started with our collaboration with Nicola and has progressively expanded to other open-source contributors.
Our latest development milestone is now available through the public MyZubster Knowledge Graph.
Explore it here: MyZubster Interactive Knowledge Graph
In this article, we'll explain our implementation, the problems we encountered, and how other developers can apply similar principles to their own projects.
1. Starting with a real contributor: Nicola
Our initial experiment involved working with Nicola, also known as N4K48.
We wanted to explore how an independent contributor could document technical work, preserve ownership of their own development environment, and connect their knowledge to a broader ecosystem.
Our collaboration has involved software development, Docker, GitHub workflows, and the documentation of technical experiments.
An important part of this process was learning to distinguish between an experiment that works locally and a fully validated integration.
For example, we prepared experimental infrastructure for a MyZubster Node Bridge, including HTTPS endpoints and Docker-related workflows.
However, preparing an accessible server is not the same as proving that an independent contributor's machine has completed every stage of a distributed integration.
This distinction influenced the entire knowledge system.
We began asking: what exactly does each piece of evidence prove?
A repository commit might document a code change. A test result can support a claim about specific behavior. A deployment record shows that a deployment occurred.
None of these records automatically proves every broader claim about a project's maturity.
We carried this principle into the design of our Knowledge Cards.
Technical references:
2. Building Knowledge Cards with supporting evidence
A Knowledge Card is a structured record that describes a specific piece of knowledge or experience.
Instead of storing a generic statement such as "I know backend development," a card can describe a particular technical activity and link to supporting evidence.
Consider this illustrative example:
{
"title": "API Integration Testing",
"domain": "Backend Engineering",
"description": "Developed tests for an API integration",
"evidence": [
{
"label": "Public GitHub Pull Request",
"url": "https://github.com/example/project/pull/123"
}
],
"verificationNote": "Public source linked; broader skill claims have not been independently verified."
}
This is a simplified example rather than the complete MyZubster production schema.
The important elements are the relationship between a claim, its source, and its verification status.
We also wanted contributors to control publication.
Our backend therefore distinguishes between private drafts and public Knowledge Cards.
The public catalog is served through:
GET /api/knowledge-evidence/public
The relevant backend query is based on two explicit conditions:
const cards = await KnowledgeDraft.find({
status: 'published',
visibility: 'public'
});
This design avoids exposing private drafts simply because they exist in the database.
It also means that creating a draft and publishing a card are separate operations.
The public catalog is not a complete inventory of every contributor's private knowledge. It contains only records that satisfy the publication requirements.
3. Turning individual records into an interactive graph
Once we had a public knowledge catalog, another problem became apparent.
A list of cards provides useful information, but it does not immediately show how everything connects.
One contributor might work across several domains. Multiple cards might reference related public evidence. Different contributors might work on separate aspects of the same technical problem.
We introduced an interactive graph to make those relationships easier to explore.
Pull Request #1438 implemented the initial public graph.
It connects four principal node types:
- Knowledge Cards
- Contributors
- Knowledge domains
- Public evidence sources
Conceptually, the initial graph can be represented as:
Knowledge Domain
|
|
Contributor ---- Knowledge Card
|
|
Public Source
The frontend retrieves public cards, builds the node and relationship structures, and renders them as an interactive visualization.
Users can search, filter, select nodes, and inspect the related information.
The implementation also preserves verification notes, which help communicate the limitations of the evidence displayed.
Try it: Interactive Knowledge Graph
4. The problem we discovered: our contributors were missing
After introducing the graph, we discovered an important limitation.
We already had several contributors with documented public GitHub activity. But many of them did not appear in the Knowledge Graph.
The reason was straightforward: the graph was built exclusively from personally published Knowledge Cards.
A public pull request was not enough to create a graph node.
We had two possible approaches.
The first was to automatically generate personal Knowledge Cards for contributors based on their repository activity.
We decided against that approach.
A public pull request does not necessarily authorize another organization to create a personal knowledge profile, publish private information, or assign qualifications.
Instead, we implemented a second evidence layer.
Our solution: separate GitHub contributions from personal Knowledge Cards
On October 2, 2026, we integrated Pull Request #1453.
The update adds selected, publicly documented GitHub contributions to the Knowledge Graph.
These contributions are represented separately from owner-published Knowledge Cards.
The expanded model now looks conceptually like this:
Knowledge Domain
/ \
/ \
Knowledge Card Public GitHub PR
| |
| |
Contributor GitHub Account
|
|
Public Evidence
This separation matters because the two types of records have different meanings.
A Knowledge Card is a record explicitly published by its owner.
A GitHub contribution record documents public activity associated with a repository.
The second record does not automatically become the first.
Preserving pull request status
We also distinguish between different contribution states.
For example:
const workStatus = {
merged: 'PR integrated',
submitted: 'PR submitted / not integrated',
closed_without_merge: 'PR closed without integration'
};
This helps prevent a common documentation mistake: presenting submitted or abandoned work as a completed production feature.
Our initial implementation uses a curated selection of public GitHub contributions. It is not an unrestricted or continuously synchronized GitHub crawler.
Records must be reviewed and updated as their underlying status changes.
The change has been merged, and the corresponding Vercel production deployment reached the ready state.
View the Implementation — PR #1453
We began the new contribution layer with documented activities from several MyZubster contributors.
These examples demonstrate how a knowledge graph can connect completely different technical domains.
NFC development and documentation
Contributor @jdjioe5-cpu has public contributions related to our Animal Registry.
The associated work covers browser-based NFC simulation, physical tag design, and API documentation.
Rather than combining these into one generic skill label, the individual contributions can be represented separately.
Sources:
Geospatial development
Contributor @leanworld7-netizen has a merged contribution addressing garden geolocation and area-based search.
This connects backend engineering with geographic data and community-garden applications.
Garden Geolocation — PR #57
Frontend and telemetry
Contributor @laurentketterle-hub has a merged contribution involving a Space Station telemetry dashboard.
It provides an example of how frontend development and monitoring can be represented within a larger knowledge network.
Telemetry Dashboard — PR #399
Automated testing
Contributor @foxxx009 has a merged contribution involving automated tests for GitHubMonitor.
Test automation is an interesting knowledge domain because the associated evidence can include both the implemented tests and their documented execution.
GitHubMonitor Tests — PR #259
Other selected records represent work involving security, documentation, and metaverse integration.
Their individual states are preserved rather than automatically presenting every submission as an accepted result.
6. From Knowledge Cards to Contributor Passports
Our next question was how to connect multiple contributions made by the same person.
That led us to introduce the Contributor Passport framework.
The idea is to organize evidence-backed knowledge records into a coherent contributor history.
The conceptual sequence is:
Contribution
|
v
Public Evidence
|
v
Knowledge Card
|
v
Contributor Passport
|
v
Optional Independent Pilot Node
We integrated the framework through PR #1445.
Contributor Passports are not automatic professional certifications.
They are intended to organize documented contributions, declared knowledge, and associated evidence.
Participation is also optional.
A contributor should not be required to publish private personal information or enroll in a separate program merely to participate in open-source development.
Read the Contributor Pilot Node Framework
7. Independent nodes and the future of distributed collaboration
An interesting extension of the Contributor Passport is the Independent Contributor Pilot Node.
The concept explores whether contributors can maintain their own development scope and technical identity while connecting relevant knowledge to MyZubster.
Potential applications include independent software projects, robotics, documentation, testing, and environmental monitoring.
However, publishing the framework is only one step.
Actually deploying independent nodes requires reproducible onboarding, clearly defined technical interfaces, and end-to-end validation.
We are treating these as separate milestones.
8. Paid Bounties and transparent contributor agreements
We have also introduced a public Paid Bounties page.
Explore MyZubster Paid Bounties
The system distinguishes proposed tasks from explicitly reserved work.
This is another example of why precise status information matters.
An interesting technical proposal should not be confused with a funded contract.
Likewise, completing a Knowledge Card should not automatically authorize a contributor's enrollment in a separate development program.
We are experimenting with connecting accepted contributions, documented evidence, optional knowledge records, and separately agreed rewards.
Our implementation is documented in PR #1444.
9. What other developers can learn from this experiment
Our development process has highlighted several principles that are useful beyond MyZubster.
First, keep the original source accessible.
A knowledge claim becomes easier to examine when people can follow its supporting evidence back to an original repository, commit, pull request, or document.
Second, model different evidence states explicitly.
Private drafts, published cards, submitted pull requests, merged contributions, and reviewed scientific results should not share a single generic verification label.
Third, separate evidence from interpretation.
A merged pull request provides evidence of integration. Interpreting the skills required to produce it may require additional context.
Fourth, respect contributor consent.
Public development activity does not automatically authorize the creation of a personal profile or the disclosure of unrelated personal information.
Fifth, test the relationships, not just individual features.
A knowledge system depends on the integrity of the connections between contributors, claims, sources, and publication states.
Our public contributor graph update introduced regression tests designed to preserve the distinction between GitHub evidence and personally published Knowledge Cards.
The change passed our CI, security, and evidence-gate workflows before integration.
10. Explore the project and contribute
We are developing MyZubster openly because we believe the knowledge generated during development should be useful to other people.
Our next challenges include expanding contributor participation, improving the accessibility of the Knowledge Graph, maintaining accurate public contribution records, and further validating independent development environments.
We welcome technical reviews, reproducible bug reports, documentation improvements, and contributions that help make the system more transparent.
Project links:
If you maintain an open-source project, we'd also be interested in discussing how you document the knowledge created by your contributors.
Do you currently rely on README files, documentation websites, GitHub discussions, contributor profiles, or something else?
Our experiment is built around one idea: preserve the evidence, document the knowledge, and make the connections visible.
MyZubster is an evolving open-source project. Public GitHub evidence, contributor-declared knowledge, independently verified results, and experimental infrastructure are represented as distinct concepts.