Tanishk Gangwar B.Tech CSE (Data Science) · Manipal University Jaipur · Batch '28
I study how information behaves in code: in commits, in adoption curves, in systems that look chaotic until you measure them properly. Most of what's below started as a clean hypothesis. Some of it ended with the data winning instead of me. I think that's the more interesting outcome to publish.
difference-in-differences quasi-experimental git mining 638k commits
Does GitHub Copilot change how people commit, causally rather than just correlationally?
flowchart LR
A[GH Archive<br/>10 repos, 2018-2024] --> B[Commit extraction<br/>638,000+ commits]
B --> C[Feature engineering<br/>files / churn / inserts]
C --> D[Panel: repo x week<br/>fixed effects]
D --> E[Pre-trend F-test]
D --> F[DiD + event study]
D --> G[Commit-message DiD<br/>mechanism check]
E --> H[Result]
F --> H
G --> H
| Metric | Effect | Inference |
|---|---|---|
| Mean files/commit | -28% | 16/16 headline tests significant under HC3; directionally consistent, decisive on 2/8 headline cells under wild cluster bootstrap |
| Mean insertions/commit | -37% | Survives WCB (repo-clustered, 9999 reps) |
| Large-commit fraction | -2.4pp | Survives HC3, few-cluster inference caveat disclosed |
| Fix-commit fraction | β = -0.030, p < 0.001 | Cleared pre-trend, message-label precision 83% (hand-validated, 100 samples) |
| Refactor-commit fraction | β = +0.007, p = 0.006 | Cleared pre-trend, message-label precision 88% (hand-validated, 100 samples) |
| Pre-trend joint F-test | passes on all 4 headline features | n/a |
Effect concentrates in existing contributors, not newcomers: people write smaller, more atomic commits once an assistant is doing the typing. A commit-message DiD adds the mechanism check, with fix-commit share falling and refactor share rising post-adoption. Full review pass added multiple-testing correction (BH-FDR), a wild cluster bootstrap given only 8-10 repo clusters, a COVID-era falsification test, a bot-commit robustness check, and hand-validated message labeling, with the paper's headline claim honestly downgraded from "robust across specs" to "directionally consistent, not decisive under conservative few-cluster inference." IEEEtran-to-ACM sigconf paper (11 pages) drafted, targeting MSR 2027.
Relation to prior work - Xu et al. 2025 (arXiv:2510.10165, Tilburg)
Xu et al. find Copilot adoption increases PR-level rework and review volume. Sekivara looks one level down, at the commit itself, and finds atomicity decreasing post-adoption. Together the two tell one story: more, smaller, more frequent commits. Sekivara supplies the commit-level mechanism underneath their PR-level result, and its clean pre-trend F-test and outlier-filtered control set are the methodological additions.
staggered-adoption DiD sun-abraham estimator bigquery 89 repos
Does adding a CODEOWNERS file causally change how fast pull requests get reviewed?
flowchart LR
A[GH Archive<br/>~21TB via BigQuery] --> B[89-repo panel<br/>staggered adoption]
B --> C[Sun-Abraham<br/>event-study DiD]
C --> D{Result by<br/>horizon}
D -->|0-18mo| E[Null on<br/>PR closing time]
D -->|23-24mo| F[Signal, flagged<br/>as confounded]
B --> G[CODEOWNERS coverage<br/>parsed at treatment date]
G --> H[Bimodal split:<br/>14 repos ≤10% / 8 repos ≥90%]
| Window | Finding | Confidence |
|---|---|---|
| 0-18 months | Null effect on PR closing time | Clean |
| 23-24 months | Two coefficients turn significant | Confounded: only 17/28 repos reach this horizon, no later-adopting comparison cohort at same horizon |
| Coverage split | 14 repos ≤10% coverage, 8 repos ≥90% | Low-coverage subset reproduces the null; high-coverage subset violates parallel trends, so coverage is a likely moderator |
Relation to prior work - Lulla, Kula & Treude 2025
A directly competing paper was found mid-analysis and incorporated rather than ignored. Their fixed RDD design structurally cannot observe the 18-24 month window Ikiru covers. The two studies are complementary in the horizons they can each speak to, not redundant.
shannon entropy leave-one-repo-out CV honest null result
Does Shannon entropy in commit histories predict upcoming software releases?
flowchart LR
A[Commit histories<br/>9 repos] --> B[Shannon entropy<br/>per commit window]
B --> C[Naive train/test split]
C --> D[72% accuracy]
B --> E[Leave-one-repo-out CV]
E --> F[AUC 0.47, chance level]
B --> G[Confound check]
G --> H[Commit volume vs entropy<br/>Spearman r = 0.817]
| Evaluation | Result | Interpretation |
|---|---|---|
| Naive split | 72% accuracy | Looked promising |
| LORO-CV | AUC 0.47 | Indistinguishable from chance |
| Confound test | Spearman r = 0.817, p = 0.007 | Entropy was re-detecting commit volume, not release prep |
| Residual-entropy check | Mean AUC 0.467 | Null holds even after regressing out the volume confound |
Status: Published as a negative result with a documented confound, not a quiet repo nobody talks about. The methodology is the part worth reading. Research direction pivoted toward testing whether entropy-flagged unusual commits predict bad downstream outcomes (fix-follows, reverts), a gap in prior anomaly-detection work.
fairness-aware ml demographic parity equal opportunity random forest
Does fixing bias in tabular ML cost accuracy, and do all mitigation strategies work equally well?
flowchart LR
A[Tabular dataset] --> B[Bias audit<br/>12 modules]
B --> C[Reweighting]
B --> D[Feature suppression]
B --> E[Post-processing]
C --> F[Fairness metrics]
D --> F
E --> F
F --> G[Random Forest<br/>accuracy check]
| Strategy | Demographic Parity Gap ↓ | Equal Opportunity TPR Gap ↓ | Accuracy |
|---|---|---|---|
| Reweighting | Best of 3 | Best of 3 | Stable |
| Post-processing | Middle | Middle | Stable |
| Feature suppression | Worst of 3 | Worst of 3 | Stable |
| Overall | 64.5% | 47.8% | Held stable throughout |
The sharper finding: naive feature suppression, the most intuitive fix, was the least effective of the three, underperforming reweighting on every fairness axis tested. Built with Dr. Chirag Joshi; pending arXiv endorsement.
Contributions to libraries with real production surface area, not toy patches.
- npm/cli - fixed a silent failure in
npm audit fixby adding asecurityDowngradegate toCanPlaceDep(PR #9754), merged. - pandas - fixed a negative-slice indexer validation bug in core indexing logic using
slice.indices()(PR #66101), merged with regression tests. - PyDriller - corrected
Commit._stats()to respect theskip_whitespacesflag (PR #320), merged; added aCommit.patchproperty exposing full unified diffs, closing a long-standing feature request (PR #321), merged. - PyGithub - added a configurable
max_rate_limit_waitcap toGithubRetry, with a newRateLimitExceededExceedsMaxWaitexception, replacing unbounded rate-limit stalls (PR #3540), in review.
go raft consensus deterministic simulation testing distributed systems
Can you make a distributed-consensus bug reproduce on demand, then run it live?
flowchart LR
A[Raft nodes in Go<br/>leader election + log] --> B[Scheduler-driven delivery<br/>+ fault injection]
B --> C[Deterministic sim testing<br/>2000-seed sweep]
C --> D[Full log replication<br/>+ KV state machine]
D --> E[Azure 3-node cluster<br/>Docker + gRPC]
E --> F[Live dashboard<br/>chaos controls]
E --> G[HTTPS via Caddy<br/>+ DuckDNS, reboot-safe]
| Phase | Scope | Status |
|---|---|---|
| 1-2 | Leader election, scheduler-driven delivery, fault injection (drops, delays, partitions) | Done |
| 3 | Full AppendEntries log replication, apply loop, KV state machine |
Done |
| 4 | Production deployment: WAL storage, gRPC transport, client API with leader-forwarding, Docker Compose 3-node cluster on Azure, toxiproxy chaos, kill-a-container failover demo | Done |
| 5 | Live dashboard (cluster state, leader crown, live KV traffic feed, Kill/Start/Isolate/Heal chaos buttons), HTTPS via Caddy + DuckDNS, systemd reboot resilience | Done |
| 6 | Empirical study on the deployed cluster | Cuttable, not started |
Deterministic simulation testing means every failure replays exactly: a 2000-seed stale-read sweep found 112 stale minority reads and zero linearizability violations. A full code audit turned up 11 numbered concurrency/correctness flaws post-deployment (stale vote replies, stale AppendEntries replies, missing no-op on election win, and more); the two most severe are fixed and verified clean under go test -race, the rest tracked as open findings. The deployed cluster survived an unattended sudo reboot and a live kill-the-leader demo (n2 killed via docker kill, n3 elected and kept serving writes) with no manual intervention.
edge ai vibration/acoustic sensing MAD/IQR gating predictive maintenance
Can a machine flag a failing bearing on-device, before it fails, without drowning in false alarms?
flowchart LR
A[Vibration/acoustic<br/>sensor stream] --> B[Two-stage MAD/IQR gate]
B --> C[Small anomaly model]
C --> D[Self-calibrating<br/>baseline]
D --> E[CWRU Bearing Data Center<br/>benchmark, 15 fault conditions]
| Test | Result |
|---|---|
| Fault detection | 100% across 15 seeded fault conditions (CWRU Bearing Data Center benchmark) |
| False positives | 0% on held-out healthy data |
| Self-calibration vs static baseline | False alarms on a legitimate operating-point change cut from 10.5% to 0% |
Solo submission (team of 1) for InnoVent-27's Edge AI for Autonomous & Intelligent Heavy Machines category, motivated directly by vocational-training exposure to plant-floor sensor data at NTPC. Virtual PoC validated end-to-end against a public benchmark before the full form and presentation deck were submitted.
html sheetjs offline-first statistical filtering
Vocational trainee with the APR/SCADA team (June-July 2026). Two shipped tools, both built around a no-pip/no-admin-rights office desktop constraint:
- A fully offline, browser-based CSV/Excel trend-report converter (single HTML file, SheetJS + JSZip bundled inline, zero install) with batch folder processing, pre-flight validation, and a compound tag-editing UI: diff-by-example renaming, character-strip, and per-position removal.
- An outlier-removal and feature-rejection pipeline for Pearson correlation analysis: a two-stage graph-level gap/leverage test ahead of point-level MAD- and IQR-based cleaning, with a PDF methodology summary produced for the team.
clip umap fastapi docker gcp
Can a machine read taste?
flowchart LR
A[25-round quiz<br/>image comparisons] --> B[CLIP ViT-B/32<br/>embeddings]
B --> C[Cosine similarity to<br/>16 aesthetic centroids]
B --> D[3D UMAP projection]
D --> E[kNN nearest-image<br/>retrieval]
A --> F[Upload & classify<br/>any photo]
| Engineering problem | Root cause | Fix |
|---|---|---|
| Docker image bloat | pip dependency-resolution bug | 9.2GB → 1.62GB |
| Session tracking silently broken | Browser secure-context restriction | Diagnosed via evidence, not guesswork |
| Slow classify response | Assumed memory issue | Actually e2-micro's documented 25% sustained CPU ceiling, measured directly |
| Repeated slow startup | UMAP re-fit on every restart | Cached fit to disk |
Free-tier GCP VM (964MB RAM) by choice: the constraint is what makes the engineering real. Free HTTPS, a real domain, zero ongoing cost. Full writeup in the repo's README.
- 🎓 Amazon ML Summer School 2026 - selected among the top ~3,000 of 134,000+ applicants (~2.2% selection rate)
- 🏆 Top 1,500 of 100,000+ participants - Google "The Big Code" competitive programming challenge
- 🥇 Dean's Academic Excellence Award - Manipal University Jaipur, Semesters 2, 3, and 4
