GitHub Fork Health Project

This project studies GitHub fork activity using GH Archive data and builds a small model for estimating fork maintenance risk.

Our main idea is to treat a fork as a time-based object: for each fork we build snapshots, describe what happened before the snapshot, and predict whether the fork is likely to become problematic in the next 30 days.

The repository is split into four main stages: data understanding, data preparation, modeling, and deployment. Each stage has its own README with the full details.

Project Structure

.
├── data_understanding/
├── data_preparation/
├── modeling/
├── deployment/
└── requirements.txt

Data Understanding

Folder: data_understanding/

This stage checks whether GH Archive has enough useful signal for the task. We look at ForkEvent, PushEvent, and PullRequestEvent, verify how fork relationships are stored, build the initial repository shortlist, and produce 180-day repository and fork activity artifacts.

The main output of this stage is a set of artifacts under:

data_understanding/main_du_artifacts/

For details, see:

data_understanding/README.md

Data Preparation

Folder: data_preparation/

This stage turns the data understanding artifacts into a model-ready dataset. We reuse the first-half 2020 artifacts, collect the second half of 2020, merge them into yearly tables, generate fork snapshots, build features, construct labels, and save the final clean dataset.

The main modeling dataset is:

data_preparation/artifacts/model_dataset_clean_final_365d.csv

For details, see:

data_preparation/README.md

Modeling

Folder: modeling/

This stage compares baseline model setups on the prepared dataset. We use a repository-level split, compare Logistic Regression with Histogram Gradient Boosting, and evaluate both full historical features and smaller live-friendly feature sets.

The strongest practical model is the Histogram Gradient Boosting setup, especially with the compact feature set that can also be used in the deployment demo.

For details, see:

modeling/README.md

Deployment

Folder: deployment/

This stage contains a lightweight Streamlit demo. The app accepts an upstream repository in owner/repo format, fetches forks from the public GitHub API, computes compact live features, scores the forks with the saved model bundle, and shows a ranked fork list.

The deployment model bundle is stored in:

deployment/artifacts/fork_health_models.pkl

For details, see:

deployment/README.md

Current internal deployment:

http://10.90.136.74:8501

The app is deployed on an Innopolis VM and is available only from inside the network. The VM may change its IP address after updates or restarts. If the deployment is unavailable, please contact @raulrail, I will give new link.

Quick Start

Install dependencies:

python3 -m pip install -r requirements.txt

Run the Streamlit demo:

streamlit run deployment/app.py

If GitHub API rate limits become an issue, set GITHUB_TOKEN before running the app.

Notes

Some data collection scripts process raw GH Archive hourly files and can take a long time to rerun. In normal project review, it is better to start from the saved artifacts and the phase-specific README files.

The label used in this project is a constructed proxy for fork maintenance risk. It is useful for modeling and comparison, but it should not be interpreted as an official GitHub status or ground-truth repository health label.