Backport Friction Replication Package

This is the replication package for an empirical study of backport friction in pull-based development: extra difficulty beyond a clean cherry-pick when a fix is transferred from mainline onto a maintained stable branch. The study combines manual coding of 500 stratified backport pull requests with automated analysis of 37,460 stable-targeting backports drawn from 223,602 pull requests in five primary repositories (Ansible, Bitcoin-part, Julia, Rails, and Kibana). A Python-only semantic-inconsistency check also uses CPython. Friction is measured in three dimensions: process inefficiency, patch incompatibility, and semantic inconsistency. The package supports prevalence measurement, merge-delay and rejection comparisons, and metadata-only triage models (Weka 3.8, 10-fold stratified cross-validation). Author names, affiliations, and identifying repository URLs for the authors are omitted to preserve double-anonymous review. Camera-ready metadata will be restored after acceptance. What this archive contains README.md — folder map, corpus notes, and how to reproduce the reported tables Mining and analysis scripts (Git history queries, GitHub REST collection, friction heuristics) Per-project pull-request exports for the five primary repositories Validated annotation tables for the 500-sample manual coding (codebook / rubric labels) Automated detector outputs for inefficiency, incompatibility (IPA1–IPA7), and semantic inconsistency Merged feature/label CSVs for prediction, including model_features/ModelFeatures_all.csv Weka evaluation artifacts used to produce the classifier results (default learners: NaiveBayes, Logistic, RandomForest, J48, MultilayerPerceptron, SGD) How to use Start with README.md. The feature table model_features/ModelFeatures_all.csv is the input for reproducing the prediction results: each row is one backport; class attributes are IsIncompatible, IsInconsistent, IsInefficient, and IsDelayed. Rows labeled NoClass on incompatibility or inefficiency are excluded so the tasks remain two-class. Identifiers and long text fields are omitted from the model export. Scope notes Unit of analysis: a pull request whose base is a maintained stable (or release) branch, not the default branch Forward porting is out of scope Inefficiency and incompatibility detectors are corpus-wide; semantic inconsistency is Python-subset only The five-repository frame reuses a previously validated backport index; it is not a random sample of GitHub License and reuse Open data and scripts are intended for research replication. GitHub metadata and diffs remain subject to the licenses of the original projects. Please cite the paper and this dataset if you reuse the archive. Related identifiers This paper (under review): Backport Friction: An Empirical Study of Stable-Branch Integration in Pull-Based Development