Goal
Rework the GitHub profile presentation so a new visitor can understand the research ecosystem, major projects, and repository relationships within roughly 30 seconds.
The current repository count is not accidental: much of the work originated in a large monolithic workspace that became too large to maintain cleanly, so it was decomposed into focused repositories with distinct responsibilities. The problem is presentation and hierarchy, not that the repositories lack purpose.
Why this matters
Many repositories currently receive similar visual weight on the profile. To an outsider, that can make a connected research program look fragmented or noisy even when the repositories are intentionally modular.
The profile should communicate a clear architectural story:
A monolithic neuromorphic / AI research workspace evolved into a collection of focused, interoperable repositories, each responsible for a specific subsystem, experiment, library, visualization layer, or infrastructure component.
The objective is not to delete legitimate work just to reduce the repository count. The objective is to expose the hierarchy and relationships clearly.
Proposed profile structure
1. Lead with a small set of flagship projects
Identify approximately three projects that represent the strongest current work and give them the highest visual prominence.
Each flagship should answer:
- What problem does this solve?
- What did I personally design or investigate?
- What is technically novel or useful?
- What measurable result or artifact exists?
- Where should a reviewer start?
2. Add a system map
Create a concise map of the repository ecosystem, grouped by function rather than listing every repository with equal detail.
Suggested categories:
- Flagship research systems
- SNN / neuromorphic libraries
- MoE / quantization tooling
- GPU / CUDA / acceleration
- Data, evaluation, and experiment infrastructure
- Visualization / analysis
- Agent orchestration and dataset generation
- Supporting libraries and bridges
- Experimental / exploratory work
- Archived or superseded work
For each repository shown in the map, include only:
- repository name
- one-line responsibility
- status
- relationship to a flagship or parent system where useful
3. Explain the monolith → modular architecture transition
Add a short paragraph explaining that the repository ecosystem grew out of a monolithic workspace and was intentionally decomposed as the codebase and research scope expanded.
This should make the repository count read as modularization and systems decomposition, rather than uncontrolled project sprawl.
4. Introduce repository status hierarchy
Use consistent status language where useful, for example:
- Flagship — actively polished and intended for external review
- Active — maintained component or supporting system
- Experimental — research prototype / exploratory work
- Archived — preserved research artifact, no longer active
Do not imply that experimental work is production-ready.
5. Connect supporting repositories back to the larger system
Where appropriate, supporting repositories should link back to their parent research program or flagship repository so visitors can navigate the architecture instead of encountering isolated projects.
6. Move deep detail out of the profile README
The profile README should remain a high-signal navigation layer.
Long architecture notes, experiment histories, implementation details, and exhaustive repository descriptions should live in repository READMEs or dedicated docs rather than overwhelming the profile landing page.
Checklist
Acceptance criteria
This issue is complete when:
- A first-time visitor can understand the overall research direction and repository architecture in about 30 seconds.
- The flagship projects are visually obvious.
- Supporting repositories appear as components of a coherent system rather than unrelated projects.
- Experimental and archived work is clearly distinguished from polished flagship work.
- The profile explains why many repositories exist without requiring a long defensive explanation.
- The profile README functions as a navigation layer rather than an exhaustive catalog.
- No meaningful repository is deleted solely to make the profile appear smaller.
Ongoing maintenance
Until September classes begin, use this issue as the recurring weekly cleanup checkpoint: update the system map, review project statuses, improve cross-links, and keep the flagship narrative aligned with the strongest current work.
Goal
Rework the GitHub profile presentation so a new visitor can understand the research ecosystem, major projects, and repository relationships within roughly 30 seconds.
The current repository count is not accidental: much of the work originated in a large monolithic workspace that became too large to maintain cleanly, so it was decomposed into focused repositories with distinct responsibilities. The problem is presentation and hierarchy, not that the repositories lack purpose.
Why this matters
Many repositories currently receive similar visual weight on the profile. To an outsider, that can make a connected research program look fragmented or noisy even when the repositories are intentionally modular.
The profile should communicate a clear architectural story:
The objective is not to delete legitimate work just to reduce the repository count. The objective is to expose the hierarchy and relationships clearly.
Proposed profile structure
1. Lead with a small set of flagship projects
Identify approximately three projects that represent the strongest current work and give them the highest visual prominence.
Each flagship should answer:
2. Add a system map
Create a concise map of the repository ecosystem, grouped by function rather than listing every repository with equal detail.
Suggested categories:
For each repository shown in the map, include only:
3. Explain the monolith → modular architecture transition
Add a short paragraph explaining that the repository ecosystem grew out of a monolithic workspace and was intentionally decomposed as the codebase and research scope expanded.
This should make the repository count read as modularization and systems decomposition, rather than uncontrolled project sprawl.
4. Introduce repository status hierarchy
Use consistent status language where useful, for example:
Do not imply that experimental work is production-ready.
5. Connect supporting repositories back to the larger system
Where appropriate, supporting repositories should link back to their parent research program or flagship repository so visitors can navigate the architecture instead of encountering isolated projects.
6. Move deep detail out of the profile README
The profile README should remain a high-signal navigation layer.
Long architecture notes, experiment histories, implementation details, and exhaustive repository descriptions should live in repository READMEs or dedicated docs rather than overwhelming the profile landing page.
Checklist
Acceptance criteria
This issue is complete when:
Ongoing maintenance
Until September classes begin, use this issue as the recurring weekly cleanup checkpoint: update the system map, review project statuses, improve cross-links, and keep the flagship narrative aligned with the strongest current work.