Écrire un commentaire

The paper looks at whether we can spot open-source projects that are starting to lose maintainability before the problem becomes obvious. It uses activity and code-quality data from 2,800 GitHub repositories and compares Random Forest, XGBoost, and a Temporal Fusion Transformer. The main finding is that contributor activity and slow PRs seem to give earlier warning signs than code metrics alone.

I read this as an empirical software engineering paper rather than a framework advertisement. I like the basic idea of looking at how a project changes over time instead of judging it from one snapshot. My comments are mostly about a few things I would want to understand better before using the framework in practice.

The dataset

1. The 2,800 repositories The paper starts with 15,000 repositories and then applies several filters. I would like to see how many repositories remain after each step. That would make it much easier to understand what the final dataset actually contains.

2. The “abandoned” label A project is considered abandoned when its commit activity drops below 20% of its historical peak and it has no merged PRs for four weeks. I think this is an important part of the whole experiment, so I would like to see a few examples of projects that received this label. Four weeks of low activity could mean different things for different projects.

The model

1. The 0.84 F1 score The TFT gets an F1 of 0.84 for the six-month prediction task. I wanted to see the Random Forest, XGBoost, and TFT results together, including precision and recall. That would make it easier to understand where the improvement from the TFT is actually coming from.

2. Prediction vs. explanation The models show that contributor distribution and PR resolution time are useful predictors. The discussion then connects this to maintainer burnout and contributors leaving the project. That explanation is interesting, but the experiment mainly shows a predictive relationship. I would separate the model result from the proposed explanation a little more clearly.

The code metrics

1. The code-quality measurements The paper uses cyclomatic complexity, code smell density, technical debt, and test coverage as product features. I would like a little more detail on how these measurements were collected across the different programming languages. In particular, it would help to explain which tools were used for each language and how missing measurements were handled.

2. The CPSI score The Composite Project Sustainability Index is presented as something an engineering team could use when checking its dependencies. I think one real repository example would help here: show the CPSI over time and which project metrics caused it to increase or decrease.

The practical side

1. The GitHub limitation The dataset focuses on popular GitHub repositories in five programming languages. The authors acknowledge this limitation, but I think it matters when the paper talks about open-source projects more generally. I would make it clearer that the conclusions are based on this particular GitHub sample rather than the whole OSS ecosystem.

Competing interests

The author declares that they have no competing interests.

Use of Artificial Intelligence (AI)

The author declares that they did not use generative AI to come up with new ideas for their review.