01 · Roasts
Dashboard, meet test suite
HOSPITAL-FLOW-DASHBOARD has ETL, schema constraints, two dashboard paths, and zero tests or CI—the pipeline is dressed for production but missing its seatbelt.
Notebook singularity
no-show-prediction packs XGBoost, ROC/PR metrics, and feature engineering into one notebook, then stops after one sampled commit.
Repository-shaped void
Source-credibility-detection-model has 0 KB, no source files, and no README. Its strongest feature is arriving and immediately leaving.
Adoption pending
Across the profile: 0 stars, 0 forks, 0 watchers, and 1 follower. The projects need users beyond their author.
Built using
Zoral
Shadows one worker for a week, then takes over their job with zero extra setup. Behaves exactly like the original.
zoral.ai
02 · Category breakdown
- Impact25% weight22F
- Consistency20% weight55D
- Quality20% weight33F
- Depth15% weight50D
- Breadth10% weight50D
- Community10% weight25F
03 · Stats
365-day commit heatmap
10 active days
Language distribution
- Python45%
- HTML33%
- Jupyter Notebook21%
- Other1%
04 · Numbers
Owned repos
non-fork
3
Commits
last 12 months
112
Followers
1
Joined GitHub
Mar 2024
05 · Top repos
MZ2839 /
HOSPITAL-FLOW-DASHBOARD
A documented, end-to-end synthetic hospital analytics project with deterministic data generation, SQLite ETL, forecasting-oriented analysis, and both Streamlit and static dashboards, but no demonstrated adoption or automated validation.
MZ2839 /
no-show-prediction
A documented Jupyter notebook develops an XGBoost no-show classifier with leakage-aware features, imbalance handling, ROC/PR evaluation, and SHAP/SMOTE plans, but it is a one-commit, untested analysis repo with no adoption signals.
MZ2839 /
Source-credibility-detection-model
Empty repository with no source files, documentation, tests, configuration, or recorded commits; only the description “ISOFT Data-Project” is present.
06 · Timeline
- Mar 17, 2024Joined GitHub
- Jun 29, 2026Created HOSPITAL-FLOW-DASHBOARD — Hospital demand
- Jun 29, 2026Created no-show-prediction
- Aug 13, 2026Created Source-credibility-detection-model — ISOFT Data-Project
- Aug 13, 2026Most recent push to Source-credibility-detection-model
07 · Compare
08 · Rubric
How this score was produced
Overall = Σ (category × weight) + gentle top-end curve
Tier thresholds
▸ How the pipeline works
- 01Scrape.Pull every non-fork repo pushed in the last 90 days, plus your contribution calendar, followers, and language byte counts — straight from GitHub's REST & GraphQL APIs.
- 02Triage.A small model reads every repo's file tree + README and picks the 20 files per repo that actually reveal how you code.
- 03Grade each repo. All repos run in parallel through a fast scoring model that reads the picked files and rates each one independently on Impact, Quality, and Depth — with evidence citations.
- 04Aggregate. A larger reasoning model combines the per-repo scores with server-computed stats (heatmap, commit cadence, language entropy, follower count) to produce the 6-dimension profile score + roasts.
- 05Correct.Deterministic server-side checks enforce anchor-scale floors (e.g. a profile with 2,000+ public commits can't score 30 Consistency) and recompute the final verdict.
~90 seconds per profile, ~$0.25 in compute. Total of ~240 files read across your top-12 repos. One rating per GitHub account per day.
▸ Data sources & caveats
- Heatmap & commit totals: GitHub GraphQL
contributionsCollection— covers the last 365 days, includes private repos when the user has opted in (default). - Language %: byte totals across the top 30 owned non-fork repos.
- Curve: a small upward nudge centered on raw score ≈ 70, capping at 100. Prevents specialists from being unfairly penalised for narrow breadth.
- Anchor corrections: when server-measured signals (e.g. privateWorkLikely, multiRepoVolume, follower count) mandate a minimum category score, the aggregation step enforces it. These are signal-conditional, not identity-based floors.