Git2KG: Mining socio-technical relationships in GitHub repositories as temporal knowledge graphs

arXiv:2611.15509v1 [cs.SE] 11 Nov 2026

Git2KG: Mining socio-technical relationships in GitHub repositories as temporal knowledge graphs Lennart Hessenauer

Lisi Qarkaxhija

Ingo Scholtes

CAIDAS Julius-Maximilians-Universität Würzburg, Germany lennart.hessenauer@uni-wuerzburg.de

CAIDAS Julius-Maximilians-Universität Würzburg, Germany lisi.qarkaxhija@uni-wuerzburg.de

CAIDAS Julius-Maximilians-Universität Würzburg, Germany ingo.scholtes@uni-wuerzburg.de

Abstract—The widespread use of Git and GitHub in open source software (OSS) projects has produced large volumes of data on collaborative software development. Existing approaches to mine those data often use graph models to (i) capture communication between developers in the issue tracker, or (ii) represent developer-developer co-authorship or developerfile code ownership networks from the editing history of code artifacts. Integrating these data in a single knowledge graph (KG) is complicated by the need to disambiguate authors and match entities from multiple sources. Moreover, most works using network analysis have taken a time-aggregated perspective that neglects temporal dynamics of collaborations. To address these issues, we present Git2KG, an extensible Python library that mines temporal knowledge graphs (TKGs) from GitHub repositories. Git2KG extracts fine-grained coediting relations and code ownership from the Git log. It further disambiguates developer identities to align the resulting graphs with management and communication networks extracted from GitHub issue trackers. Git2KG supports temporal analysis by slicing development events into fixed-size, non-overlapping time windows, yielding a series of knowledge graph snapshots per repository. It further supports computing node features and labels for downstream machine learning tasks. Snapshots can then be exported to PyTorch Geometric, PathPyG, and NetworkX for temporal network analysis, visualization, and graph learning. Index Terms—knowledge graph, data mining, software repository, network science

I. I NTRODUCTION OSS has become increasingly popular over the last decades and forms the backbone of our digital society. Such software is often developed by a large and volatile community of developers, which introduces challenges in the management of source code contributions and communication between developers and users. Git and GitHub, specifically its issue tracker, address those challenges: Git facilitates the management of source code, while the GitHub issue tracker provides a platform for communication. The widespread usage of those systems introduces large volumes of data about the software development process that are logged in the respective systems. These data have attracted interest in the research field Mining Software Repositories (MSR) [1]–[3]. One popular way to model these data is to encode the complex relations between contributors, issues, and source code as graphs [4]–[15]. However, most methods either focus on the relationships between developers and code, co-

authorship dependencies between developers, or links that model communication patterns of contributors. The MSR community lacks a reusable graph mining tool which captures all of these relationships – spanning from fine-grained source code edits over commit and code ownership, to communication between users on and with the GitHub issue tracker – in a single comprehensive knowledge graph (KG). To fill this gap, we present Git2KG, a Python library which supports the mining of TKGs with arbitrary time resolution from repositories on GitHub. Git2KG leverages data from the Git log and the GitHub issue tracker, mining detailed knowledge graph models which represent different types of relations in OSS development. To connect data from the two sources, we align authors and committers in Git and GitHub user accounts, using identity disambiguation. The KGs mined by Git2KG are suitable for network analysis, visualization, and machine learning. For the latter, Git2KG provides extendable engines for node feature and label computation. We provide the tool through GitHub1 . The remainder of this work is structured as follows: In Section II, we present existing graph models and graph mining tools modelling the software development process. Section III presents the schema of the TKGs mined by Git2KG, the data loading pipeline, entity disambiguation, as well as the extendable feature and label computation and export modules. In Section IV, we evaluate the mining performance and actor alignment of our library. Finally, we conclude the work in Section V by showing the limitations of our approach and pointing toward further research. II. R ELATED W ORK A number of works in the context of repository mining use graphs or networks to model events from software engineering. Developer communication has been studied by applying social network analysis to data from IRC channels [4], mailing lists [5], [6], and bug trackers [7]–[10], [16]. Co-authorship networks instead link developers who edited the same file [11], [12]. MacLean et al. [14] enhanced such models to KGs connecting authors, revisions, and files based on code authorship and file modifications. The popularity of GitHub 1 https://github.com/lennart-h/git2kg

4 node types · 20 relations

GitHub

issue create_issue, comment_issue, close_issue reopen_issue, review_pull, merge_pull issue_comment, mentions review, review_request assign_issue

referenced_on

assigned_to

actor

edit_add edit_delete

the actor entity is the common entity to in both datasources

author_commit committer_commit

Git

commit

modifies

child_of mined from GitHub (13)

mined from Git (7)

file co_commit excluded by default excluded by default

Fig. 1. Schema of Git2KG knowledge graphs. The color encodes the data source. The actor entity appears in both sources as the aligning entity.

motivated researchers to model data from the platform as graphs, including reviewing behavior [17], collaboration [18], comment networks [19], or project follower relationships [20]– [22]. Beyond such single datasets, several tools to mine graphs from repositories exist. GraphRepo [13] extracts multirelational KGs connecting developers, commits, branches, files, and methods from the Git development history. TNM [23] is a Kotlin tool which mines “people networks” and “software networks” from Git and connects the two subgraphs with relations between people and software components. Kaiaulu [24] mines socio-technical networks combining email communication and coarse-grained file authorship. As developers editing the same file may change unrelated code regions in the file, git2net [25] defines co-editing relations on the line level instead of file-based co-authorship as the notion for collaboration. It builds temporal co-editing networks using the Git log of a repository, which have been used to study productivity [15]. To the best of our knowledge, no network model or mining tool connects fine-grained co-edits with code ownership and communication on GitHub. Git2KG fills that gap. III. M INING P IPELINE AND L IBRARY D ESIGN In this section, we discuss the design of Git2KG and how it mines TKGs from GitHub repositories. We explain the KG schema, data loading in Git2KG, and identity disambiguation. Next, we show how we use time slicing to gain a sequence of KGs, before finishing the pipeline with feature and label computation and exports to other data formats. A. Knowledge Graph Schema Git2KG mines KGs with four entity types: actors, commits, files, and issues, where pull requests (PRs) are treated as a special kind of issue. Fig. 1 shows the full schema. Commits and files are mined exclusively from Git, and issues exclusively from GitHub. Actors appear in both sources, as commit authors and committers in Git and as issue tracker users on GitHub, and therefore serve as the entity that aligns the two

subgraphs. Git2KG extracts 20 typed relations between these entities, seven from the Git history and 13 from the GitHub issue tracker. Each relation corresponds to a timestamped development event, which allows us to slice the graph into snapshots. From Git, we extract co-editing relations between actors following git2net [25]: an edit_add (edit_delete) edge links an actor who adds (deletes) code to the author who last edited the affected line. The author_commit and committer_commit relations declare the commit ownership of actors, child_of encodes the relation between a parent and a child commit, and the modifies relation links commits to the files in their change set. Git2KG also supports the extraction of the co_commit relation, which links files that are changed in the same commit, but excludes the extraction of this relation by default as it is a sole projection of the modifies relation and produces only clique subgraphs with no additional information encoded. From the GitHub issue tracker, we extract the create_issue, comment_issue, close_issue, reopen_issue, review_pull, and merge_pull relations from actors to issues directly from the issue events and the assigned_to relation from issues to actors. The cross-referenced event of the issue tracker yields the referenced_on relation between two issues if one is referenced on the other. Following [10], the issue_comment relation links two actors if the first commented right after the second on the same issue. The mentions relation encodes whenever an actor uses the @-mention feature to address a comment directly to another actor. The relations review, review_request and assign_issue encode the actor-to-actor interactions while solving an issue or PR. B. Data Loading Git2KG loads data from both Git and GitHub using the GitLoader, GitHubLoader, and GitHubGraphQLLoader classes, which are proxied by the Dataloader class. It unifies the interface for data loading and streams the loaded data points to an implementation of the PersistenceManager. Implementations of that interface save and retrieve data points using a persistence backend, and enable incremental restarts of data loading. We provide a simple implementation of the PersistenceManager based on CSV files. Users of the package can, however, provide their own implementations of the interface, e.g., to integrate the data loading into existing ecosystems. GitLoader loads data from Git by traversing the commit history in a repository from the first to the last commit using PyDriller [1]. Doing so, it extracts data points corresponding to commits, line edits, and modified files. Commits and modified files are directly read from the commit log, but co-edits are only implicitly encoded in the version history of Git. For every file in a commit, we use PyDriller’s ModifiedFile to get a list of modifications in the file, apply blame on the previous version (parent commit) of the file, and merge the two lists.

seconds (median)

This yields pairs of previous authors and edits per modified line. We conduct data loading from Git on an offline clone of the repository to not be constrained by rate limits or third-party API availability. The loading of those data points is, however, still relatively expensive in computation. To minimize the loading time for the data points, we split the commit set of a repository into chunks of 20 commits and process them in parallel. GitHubLoader and GitHubGraphQLLoader are interchangeable loaders for issues, issue comments, reviews, events, and issue timeline events, using the GitHub REST API and GraphQL API, respectively. Both loaders require a GitHub access token to gain access to their corresponding API. GraphQL retrieves related data points (comments, reviews, events, etc.) together with their issue, which reduces ratelimit overhead, at the cost of persisting them only after the download completes instead of incrementally during the download. It also provides HTML bodies, which enables us to use hovercard markup to extract @-mentions instead of relying on pattern matching. This avoids false positives from code snippets like Java annotations or Python decorators. We therefore use GraphQL by default.

250 200 150 100 50 0

commits edits modified files all three

1

2

4

processes

8

16

Fig. 2. Loading time of the Git-based extraction stages with different numbers of cores in seconds. The line represents the median loading times across five runs. The band represents the minimum and maximum loading time of five runs. The runs were conducted on an AMD Ryzen AI 9 HX 370.

are equal to or greater than the lower border of the time slice and strictly less than the upper border of the time slice. We then extract the edges between the nodes for each time slice based on the corresponding data points, ensuring temporal integrity of extracted edges. Extracting one KG per time slice yields a series of time-aggregated KG snapshots per repository, i.e., a TKG.

C. Entity Alignment and Disambiguation

E. Features, Labels, and Exports

As we encode the development process across long time ranges with Git2KG, it is crucial that the identifiers of the entities are stable over time. This is unproblematic for issues and commits, which have project-global immutable identifiers (issue number and hash). Files are identified by their path, which changes when a file is moved or renamed. We therefore assign each file a numerical ID when it is added and follow it through renames, using the modification types recorded in the commit history. This yields a stable ID for every modified file in every commit. Actors are the only entity present in both sources, so aligning Git identities with GitHub accounts connects the two subgraphs. While users on GitHub carry a unique numeric identifier, Git identifies authors and committers only by name and email, and one person may use several of each. We therefore run gambit [26], a disambiguation tool which matches name–email pairs through string-similarity and exact-match rules, on all identities from Git and GitHub. GitHub users often keep their email addresses private, so gambit cannot match them if their names also differ. For these cases, we use GitHub’s commit API, which links commits to the account whose verified email matches the commit email, and merge the corresponding actors.

Apart from creating edges between entities, we can also use the extracted data to compute features and labels of entities for downstream machine learning tasks. The computation of features is handled by entity-type-specific implementations of the FeatureExtractor class, which can be seamlessly extended by users. On KG snapshot creation, all provided features are computed and then compiled into a feature matrix. Features change as more information becomes available over time, while not being instantaneous like edges, but describing an entity throughout its lifetime. As a consequence, we provide the full historical data to the feature extractors, by not applying the lower bound constraint to time slicing. Node labels are computed analogously using implementations of the LabelExtractor class. As labels might be used for forecasting tasks, label extractors have access to all loaded data points, irrespective of their timestamp. Edges, feature matrices, and labels of all snapshots are bundled in a NetworkSnapshots object, which implementations of NetworkExporter convert into network objects keyed by timestamp. Git2KG ships exporters for PyTorch Geometric [27], PathPyG2 , and NetworkX3 .

D. Time Slicing As all events in Git and GitHub are timestamped, the relations mentioned above carry temporal information. To encode this temporal information in a TKG, we slice the loaded data into non-overlapping time windows of equal size. The granularity of the time slices is fully configurable by the user. One time slice contains all data points whose timestamps

IV. E VALUATION AND D EMONSTRATION In this section, we present evaluation results regarding Git mining performance and actor disambiguation. We further demonstrate potential use cases for TKGs mined with Git2KG. For the analysis and demonstration, we use the TKG mined from the xz-utils project4 . The xz-utils project 2 https://www.pathpy.net/ 3 https://networkx.org 4 https://github.com/tukaani-project/xz

March 2024

actor issue commit file actor actor: edit add, edit delete, issue comment, mentions, review actor commit: author commit, committer commit actor issue: close issue, comment issue, create issue, merge pull, review pull commit commit: child of commit file: modifies issue issue: referenced on Fig. 3. Visualization of two consecutive monthly snapshots of the TKG mined from the repository of xz-utils. Color and shape of the nodes indicate the entity type. The color of the edge refers to the entity type of its end node. The shape of the edge’s line indicates the entity type of its start node. The security breach was discovered in March 2024.

is a widely used compression library which gained massive attention in March 2024, when a malicious backdoor was discovered in a published tarball of the project. We mine the repository with Git2KG and extract KG snapshots from monthly time windows. The dataset contains 3142 commits, 447650 edits, 252 issues with 1131 comments, 236 issue events, and 244 reviews. We only use snapshots after October 2022, as the project started using the issue tracker that month. In Fig. 3, we visualize two snapshots from the TKG using graph exports from the NetworkXExporter of Git2KG. For February 2024, we observe that the graph is dominated by relations and entities related to commits, indicating strong development activity in that time slice. We note that this is not necessarily related to the introduction of the backdoor, but might be just a consequence of planned releases in that month. In March 2024, when the backdoor was discovered, we see far more relations encoding communication on the issue tracker, which is likely due to users commenting on the publication and related posts. A. Mining Performance Fig. 2 shows the median loading times in seconds for the Git-related data points on the xz-utils repository across five runs. Comparing the loading time using only one process with the loading time using multiple processes, we observe that the median loading time for all data points drops from 279.56s to 77.59s when using 16 processes instead of one, i.e., the loading is roughly 3.6 times faster. We observe the strongest speedup of 4.38 for the edit data points, which is expected since loading edits is computationally the most expensive operation. For loading modified files, we see a weak speedup of 1.27, comparing 16 processes with one. Interestingly, the modified files are actually loaded more slowly for two, four, and eight processes than just using one process. This could be due to the overhead of chunking the commits and passing them to the subprocesses. Since the loading of a modified file data point is

share actors active

February 2024

GitHub only both Git only

50 0 1.0 0.5 0.0

2023

2024

2025

2026

Fig. 4. Total number and share of actor entities that appear as the start node of an edge across snapshots mined from the xz-utils repository. The color of the curves indicates whether the entity was subject to an edge mined from Git, GitHub, or both.

essentially equal to converting PyDriller’s ModifiedFile, the operation is computationally cheap, and the orchestrating overhead for multiprocessing has a bigger impact. B. Actor Alignment If Git authors and committers were mapped to different entities than their GitHub user accounts, the two subgraphs would be disconnected. Fig. 4 shows, for each monthly snapshot, the number and share of actors that are subject to edges from Git only, GitHub only, or both. We observe that in most snapshots, actors that are active in Git are also active on GitHub, as shown by the orange curve. This demonstrates that actor alignment connects the two subgraphs. The peak of GitHubonly actors around March 2024 likely reflects the increased communication following the disclosure of the backdoor. V. C ONCLUSION AND L IMITATIONS We present Git2KG, a TKG mining library for GitHub repositories, that aligns entities from Git and GitHub to form connected KG snapshots. The library is extendable in terms of feature and label computation, data export, and loading persistence, and therefore enables users to adjust the setup to their needs and integrate the library into existing ecosystems. We mine KGs with a schema of relations that describe how actors interact with each other, with the issue tracker, and with repository artifacts. However, we do not represent source code content or structure, continuous integration outcomes, forks, or line-level code review comments. Our models focus on collaborative patterns and are currently not suitable for analysis and learning tasks on program semantics. These limitations are subject of our further research. While we mine data from Git logs offline, we still depend on APIs of GitHub to load the corresponding data points. Therefore, we rely on a volatile data source which might change its interface in the future. We further note that, while our tool is applicable to every repository on GitHub, users still need to carefully select the repositories they mine [3]. Migrations from other code hosting tools to GitHub or the usage of external issue trackers might obfuscate the mined data. In future research, our tool could be used for large-scale analyses of the open-source ecosystem, similar to [15], or machine learning tasks, like predicting developer turnover [28].

R EFERENCES [1] D. Spadini, M. F. Aniche, and A. Bacchelli, “Pydriller: Python framework for mining software repositories,” in Proceedings of the 2018 ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering, ESEC/SIGSOFT FSE 2018, Lake Buena Vista, FL, USA, November 04-09, 2018, G. T. Leavens, A. Garcia, and C. S. Pasareanu, Eds. ACM, 2018, pp. 908– 911. [2] C. Bird, P. C. Rigby, E. T. Barr, D. J. Hamilton, D. M. Germán, and P. T. Devanbu, “The promises and perils of mining git,” in Proceedings of the 6th International Working Conference on Mining Software Repositories, MSR 2009 (Co-located with ICSE), Vancouver, BC, Canada, May 1617, 2009, Proceedings, M. W. Godfrey and J. Whitehead, Eds. IEEE Computer Society, 2009, pp. 1–10. [3] E. Kalliamvakou, G. Gousios, K. Blincoe, L. Singer, D. M. Germán, and D. E. Damian, “The promises and perils of mining github,” in 11th Working Conference on Mining Software Repositories, MSR 2014, Proceedings, May 31 - June 1, 2014, Hyderabad, India, P. T. Devanbu, S. Kim, and M. Pinzger, Eds. ACM, 2014, pp. 92–101. [4] M. Cataldo and J. D. Herbsleb, “Communication networks in geographically distributed software development,” in Proceedings of the 2008 ACM Conference on Computer Supported Cooperative Work, CSCW 2008, San Diego, CA, USA, November 8-12, 2008, B. Begole and D. W. McDonald, Eds. ACM, 2008, pp. 579–588. [Online]. Available: https://doi.org/10.1145/1460563.1460654 [5] C. Bird, A. Gourley, P. T. Devanbu, M. Gertz, and A. Swaminathan, “Mining email social networks,” in Proceedings of the 2006 International Workshop on Mining Software Repositories, MSR 2006, Shanghai, China, May 22-23, 2006, S. Diehl, H. C. Gall, and A. E. Hassan, Eds. ACM, 2006, pp. 137–143. [Online]. Available: https://doi.org/10.1145/1137983.1138016 [6] J. Roberts, I. Hann, and S. Slaughter, “Communication networks in an open source software project,” in Open Source Systems, IFIP Working Group 2.13 Foundation on Open Source Software, June 8-10, 2006, Como, Italy, ser. IFIP, E. Damiani, B. Fitzgerald, W. Scacchi, M. Scotto, and G. Succi, Eds. Springer, 2006, pp. 297–306. [Online]. Available: https://doi.org/10.1007/0-387-34226-5 30 [7] A. Sureka, A. Goyal, and A. Rastogi, “Using social network analysis for mining collaboration data in a defect tracking system for risk and vulnerability analysis,” in Proceeding of the 4th Annual India Software Engineering Conference, ISEC 2011, Thiruvananthapuram, Kerala, India, February 24-27, 2011, A. Bahulkar, K. Kesavasamy, T. V. Prabhakar, and G. Shroff, Eds. ACM, 2011, pp. 195–204. [Online]. Available: https://doi.org/10.1145/1953355.1953381 [8] M. S. Zanetti, I. Scholtes, C. J. Tessone, and F. Schweitzer, “The rise and fall of a central contributor: Dynamics of social organization and performance in the GENTOO community,” in 6th International Workshop on Cooperative and Human Aspects of Software Engineering, CHASE 2013, San Francisco, CA, USA, May 25, 2013. IEEE Computer Society, 2013, pp. 49–56. [Online]. Available: https://doi.org/10.1109/CHASE.2013.6614731 [9] M. S. Zanetti, I. Scholtes, C. J. Tessone, and F. Schweitzer, “Categorizing bugs with social networks: a case study on four open source software communities,” in 35th International Conference on Software Engineering, ICSE ’13, San Francisco, CA, USA, May 18-26, 2013, D. Notkin, B. H. C. Cheng, and K. Pohl, Eds. IEEE Computer Society, 2013, pp. 1032–1041. [Online]. Available: https://doi.org/10.1109/ICSE.2013.6606653 [10] J. Howison, K. Inoue, and K. Crowston, “Social dynamics of free and open source team communications,” in Open Source Systems, IFIP Working Group 2.13 Foundation on Open Source Software, June 8-10, 2006, Como, Italy, ser. IFIP, E. Damiani, B. Fitzgerald, W. Scacchi, M. Scotto, and G. Succi, Eds. Springer, 2006, pp. 319–330. [Online]. Available: https://doi.org/10.1007/0-387-34226-5 32 [11] S. Huang and K. Liu, “Mining version histories to verify the learning process of legitimate peripheral participants,” in Proceedings of the 2005 International Workshop on Mining Software Repositories, MSR 2005, Saint Louis, Missouri, USA, May 17, 2005. ACM, 2005. [Online]. Available: https://doi.org/10.1145/1083142.1083158 [12] A. Meneely, L. A. Williams, W. Snipes, and J. A. Osborne, “Predicting failures with developer networks and social network analysis,” in Proceedings of the 16th ACM SIGSOFT International Symposium on Foundations of Software Engineering, 2008, Atlanta,

Georgia, USA, November 9-14, 2008, M. J. Harrold and G. C. Murphy, Eds. ACM, 2008, pp. 13–23. [Online]. Available: https://doi.org/10.1145/1453101.1453106 [13] A. Serban, M. Bruntink, and J. Visser, “Graphrepo: Fast exploration in software repository mining,” CoRR, vol. abs/2008.04884, 2020. [Online]. Available: https://doi.org/10.48550/arXiv.2008.04884 [14] A. C. MacLean and C. D. Knutson, “Apache commits: social network dataset,” in Proceedings of the 10th Working Conference on Mining Software Repositories, MSR ’13, San Francisco, CA, USA, May 18-19, 2013, T. Zimmermann, M. D. Penta, and S. Kim, Eds. IEEE Computer Society, 2013, pp. 135–138. [Online]. Available: https://doi.org/10.1109/MSR.2013.6624020 [15] C. Gote, P. Mavrodiev, F. Schweitzer, and I. Scholtes, “Big data = big insights? operationalising brooks’ law in a massive github data set,” in 44th IEEE/ACM 44th International Conference on Software Engineering, ICSE 2022, Pittsburgh, PA, USA, May 25-27, 2022. ACM, 2022, pp. 262–273. [Online]. Available: https://doi.org/10.1145/3510003.3510619 [16] T. Wolf, A. Schröter, D. E. Damian, and T. H. D. Nguyen, “Predicting build failures using social network analysis on developer communication,” in 31st International Conference on Software Engineering, ICSE 2009, May 16-24, 2009, Vancouver, Canada, Proceedings. IEEE, 2009, pp. 1–11. [Online]. Available: https://doi.org/10.1109/ICSE.2009.5070503 [17] N. Zöller, J. H. Morgan, and T. Schröder, “A topology of groups: What github can tell us about online collaboration,” Technological Forecasting and Social Change, vol. 161, p. 120291, 2020. [18] G. P. Oliveira, A. F. C. Moura, N. A. Batista, M. A. Brandão, A. C. Hora, and M. M. Moro, “How do developers collaborate? investigating github heterogeneous networks,” Softw. Qual. J., vol. 31, no. 1, pp. 211–241, 2023. [19] Y. Yu, H. Wang, G. Yin, and T. Wang, “Reviewer recommendation for pull-requests in github: What can we learn from code review and bug assignment?” Inf. Softw. Technol., vol. 74, pp. 204–218, 2016. [20] K. Thakrar and A. Chauhan, “Github stargazers | building graph- and edge-level prediction algorithms for developer social networks,” CoRR, vol. abs/2502.00058, 2025. [21] D. Yan and B. Wang, “Collaborative similarity analysis of multilayer developer-project bipartite network,” CoRR, vol. abs/1703.03093, 2017. [22] Y. Hu, S. Wang, Y. Ren, and K. R. Choo, “User influence analysis for github developer social networks,” Expert Syst. Appl., vol. 108, pp. 108–118, 2018. [23] N. Sviridov, M. Evtikhiev, and V. Kovalenko, “TNM: A tool for mining of socio-technical data from git repositories,” in 18th IEEE/ACM International Conference on Mining Software Repositories, MSR 2021, Madrid, Spain, May 17-19, 2021. IEEE, 2021, pp. 295–299. [Online]. Available: https://doi.org/10.1109/MSR52588.2021.00041 [24] C. V. Paradis and R. Kazman, “Building the MSR tool kaiaulu: Design principles and experiences,” in Software Architecture - 15th European Conference, ECSA 2021 Tracks and Workshops; Växjö, Sweden, September 13-17, 2021, Revised Selected Papers, ser. Lecture Notes in Computer Science, P. Scandurra, M. Galster, R. Mirandola, and D. Weyns, Eds., vol. 13365. Springer, 2021, pp. 107–129. [Online]. Available: https://doi.org/10.1007/978-3-031-15116-3 6 [25] C. Gote, I. Scholtes, and F. Schweitzer, “git2net: mining time-stamped co-editing networks from large git repositories,” in Proceedings of the 16th International Conference on Mining Software Repositories, MSR 2019, 26-27 May 2019, Montreal, Canada, M. D. Storey, B. Adams, and S. Haiduc, Eds. IEEE / ACM, 2019, pp. 433–444. [Online]. Available: https://doi.org/10.1109/MSR.2019.00070 [26] C. Gote and C. Zingg, “gambit - an open source name disambiguation tool for version control systems,” in 18th IEEE/ACM International Conference on Mining Software Repositories, MSR 2021, Madrid, Spain, May 17-19, 2021. IEEE, 2021, pp. 80–84. [Online]. Available: https://doi.org/10.1109/MSR52588.2021.00021 [27] M. Fey and J. E. Lenssen, “Fast graph representation learning with pytorch geometric,” CoRR, vol. abs/1903.02428, 2019. [Online]. Available: http://arxiv.org/abs/1903.02428 [28] M. Foucault, M. Palyart, X. Blanc, G. C. Murphy, and J. Falleri, “Impact of developer turnover on quality in open-source software,” in Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering, ESEC/FSE 2015, Bergamo, Italy, August 30 - September 4, 2015, E. D. Nitto, M. Harman, and P. Heymans, Eds. ACM, 2015, pp. 829–841.

Related documents

• Git2KG: Mining socio-technical relationships in GitHub repositories as temporal knowledge graphs#1659091
• What Git Does Not Record: Provenance Legibility in Two AI-Assisted Research Repositories#1412896
• An open source knowledge graph ecosystem for the life sciences#482787
• Community-centric modeling of citation dynamics explains collective citation patterns across different knowledge systems.#1589621
• Visualizing GitHub Contributor Activity in ExplorViz / Johannes Klindt#1311011