Open source software project pull request prediction method based on deep learning model

Abstract

The invention discloses an open source software project pull request prediction method based on a deep learning model, which is used for identifying and predicting potential pull request contribution from an open source software project branch, and comprises the following steps: modeling submission information of an open source software copy, and simulating a creation process of real contribution; key submission subsets in the submission history are screened by designing a time sequence filtering strategy; and finally, constructing an identification framework for potential pull request contribution through character and code features in copy submission. The Early pull request framework has the advantages of being advanced, accurate and extensible, and can help an open source project manage branches and pull requests more efficiently, optimize a development process, improve project collaboration efficiency and the like by predicting submission contribution in advance.

Description

Technical Field

[0001] The present invention relates to a method for predicting pull requests for open source software projects based on a deep learning model, and belongs to the technical field of software development. Background Art

[0002] The copy-and-pull-based collaborative development model has proven to be very successful in modern open source software development. In this model, any developer interested in an open source project can first create his or her own copy of the source repository. The developer can then modify his or her copy independently without relying on or obtaining permission from the source repository owner. If the developer wants to contribute changes back to the source repository, he or she can create a pull request, requesting the maintainer of the source repository to review and merge the changes from the copy. Copies are essential to open source software development because they are an important source of contributions. Many copies are often considered a sign of the popularity of an open source project.

[0003] However, independent development in forks can lead to inefficiencies, especially when fork owners do not coordinate their work effectively. Research shows that forks and pull development practices can lead to inefficiencies such as contributions being lost, rejected, or redundant. Summary of the invention

[0004] Purpose of the invention: In view of the problems and shortcomings in the prior art, the present invention provides a pull request prediction method for open source software projects based on a deep learning model. Analyzing the development task workflow and collaboration mode in open source software, especially by predicting the generation of pull requests, can effectively evaluate the organizational efficiency of project collaboration, and help the development team identify inefficient links and optimize the collaboration process. In this context, the pull request prediction framework for open source software projects based on a deep learning model can predict which submissions may evolve into pull requests by intelligently analyzing code submissions, submission messages, and code change content. This not only helps to improve development efficiency, but also reduces redundancy and communication costs in team collaboration, thereby promoting the efficient development of open source software projects.

[0005] Technical solution: A method for predicting pull requests for open source software projects based on a deep learning model, which obtains normative statistical parameters by counting the copy modifications in the open source software; and uses the statistical parameters for statistical screening modeling; Use deep models to deeply model the text and code modification information of open source software; Finally, we use a combination of statistical screening models and deep feature models to predict potential lost contributions in open source software, and based on the prediction results, we further remind and warn of contributions that are potentially worthy of merging into the main repository.

[0006] The above method specifically comprises the following steps: Step 1: Obtain the required replica behavior stream data from the open source project. Assume that data of N open source projects are obtained from the open source software repository. The set Z represents all open source projects, where Z = {z1, z2, …zi, …,zN}, i = 1, …, N, where N is the number of open source projects and zi represents the i-th open source project in the obtained data set.

[0007] Step 2: Get the copy work records of all open source projects in set Z, sort all the copy work record data by time and store them in database W.

[0008] Step 3: Get data from the workflow database W. For the jth action flow record wij of the i-th project in W, perform data cleaning on each replica modification record to remove invalid or duplicate pull requests. Perform text processing on each replica submission file, including word segmentation, stop word removal, and stem extraction of the submission information. Finally, the set of all replica modification sequences is obtained, called the total replica modification sequence S.

[0009] Step 4: Count the replica modifications in the open source software to obtain a normative statistical parameter set P. According to the parameter set P, thresholds such as the pull jump ratio and the pull commit ratio can be set to filter out qualified replica modifications. Next, select a suitable statistical screening method (such as a decision tree), establish a statistical screening model TF, and use the screening model to take the entire replica modification sequence S as input to extract the potential commit set.

[0010] Step 5: Model the text and code modification information of open source software through a deep model, which is called a deep feature model M. First, collect relevant text and code modification data from the version control system, including submission information Message and code difference Code Diff data. And clean and preprocess them. Then, extract text features (such as TF-IDF and word vectors) and code features (such as syntax trees and complexity), and combine them to form a comprehensive feature set. With a given set of feature sets, design a set of convolutional network-based recognition modules that conform to their feature properties.

[0011] Step 6: Apply the statistical screening model TF obtained in step 4 and the deep feature model trained in step 5 to the actual open source project, make predictions on pull requests based on code modifications and submitted text, and collect feedback information to continuously iterate and improve the performance and applicability of the model.

[0012] The above step 1 obtains the required replica behavior process data from the open source platform. The data of each project obtained meets the data volume scale, and the obtained replica modification information is filtered and integrated. The final process data includes project developers, replica development code and text and other information.

[0013] In the step 2, for each open source project Zi in the set Z, all copy behavior process records contained in each open source project are obtained, and stored in the workflow database W after being sorted by time.

[0014] In step 3, data preprocessing is performed on each replica behavior flow record wij to remove irrelevant redundant information and retain only the specific description of the behavior, i.e., text modification, participant, code modification, and modification time. The set of all replica modification sequences is obtained, which is called the entire replica modification sequence S.

[0015] The above step 4 specifically includes Step 4.1: From the replica workflow database W, define four key statistical parameters to obtain a normative statistical parameter set P to understand how contributors make planned choices when creating pull requests. The four key statistical parameters for each project replica wij include: the number of pull requests created by each Fork; the number of commits included in each pull request; the number of skipped commits; the proportion of skipped commits. By analyzing the submission records of open source projects, the specific values ​​of the above key statistical parameters are calculated to provide key parameters for statistical screening modeling.

[0016] Step 4.2: Based on the statistical parameter set P obtained in step 4.1, a statistical screening process is designed to screen the appropriate set of commits to build pull requests. In the statistical screening process of the entire commit set, multiple parameters are set, including the maximum number of commits and the maximum number of skipped commits, to balance the build efficiency and coverage, ensuring that the filtered pull request combination is both efficient and fully covers possible commits.

[0017] Step 4.3: Use the conclusions of steps 4.1 and 4.2 to filter the submission set of all replicas, and obtain the behavior record data in the filtered replica submission, that is, the sequence sij. Since the replica modification records are arranged in chronological order, each replica behavior contains the following triple information: (r, t, c), where r is the developer mark of the behavior; t is the label of the modification; and c is the detailed content of the modification.

[0018] The above step 5 specifically includes Step 5.1: Extract relevant commit records from the triples (r, t, c) obtained in step 4.3, including commit messages and code differences. Perform cleaning operations such as word segmentation, stop word filtering, and word form restoration on the commit messages to remove noise information; for code differences, remove meaningless changes (such as comment modifications and format adjustments), and parse the code structure into a syntax tree structure for easy analysis. Finally, align the text with the code data to form a one-to-one corresponding cleaned feature data set.

[0019] Step 5.2: According to step 5.1, in the model prediction process, a given potential pull request consists of a combination of several submissions, and its prediction task is modeled as a binary classification problem. For each potential PR combination, feature extraction is performed separately for the content feature Xc and statistical feature Xs. The content feature Xc contains the submission message and code difference. After being extracted by the pre-trained large language model, a representation vector with a dimension of 768 is obtained. In order to align the representation vector with the statistical feature dimension, the representation vector is reduced to 32 dimensions through a standard convolution module. The statistical feature Xs is directly encoded into a 32-dimensional feature representation.

[0020] Step 5.3: According to step 5.2, we get the vector representations Xc and Xs of the two features, align them and concatenate them column-wise to form a comprehensive feature Z=[Xc, Xs] with a dimension of 64. The comprehensive feature is input into a 64-dimensional perceptron module to complete feature fusion. The fused feature is input into the fully connected layer to get the prediction output.

[0021] The above step 6 specifically includes the following steps: Step 6.1: Use the trained deep feature model to predict actual open source projects. For each new code commit, the model generates a prediction result of the possible commit set becoming a pull request based on the code modifications and commit messages (i.e., content features) in the commit and statistical features.

[0022] Step 6.2: By providing feedback on incorrectly labeled or unsuccessfully predicted objects, analyzing these feedbacks helps identify the model’s error types and room for improvement. Early warnings are issued to main repositories that have not submitted contributions in a timely manner, indicating that contributions between these projects may be about to be lost. The present invention has the following beneficial effects: The method for predicting pull requests for open source software projects based on deep learning models proposed in the present invention simulates the generation process of real contributions by deeply modeling the submission information in the open source software copy. Specifically, the present invention first analyzes the code changes and submission messages submitted by the copy to mine the potential that may be converted into pull requests. Then, a statistical screening model TF is designed to screen the key submission subsets in the submission history, so as to accurately capture the submissions that have made actual contributions to the project. This screening strategy can effectively filter out irrelevant or low-value submissions and improve the accuracy of prediction. When constructing an identification framework for potential pull request contributions, the present invention combines text features (such as submission messages, code comments, etc.) and code features (such as code differences, modification frequency, etc.) in the copy submission, and conducts comprehensive analysis through a deep learning model, so as to accurately identify which submissions may evolve into pull requests. This identification framework can not only improve the efficiency of prediction, but also identify potential contributions in the early stages of the project, providing valuable decision support for maintainers.

[0023] Compared with traditional open source project management methods, the Early pull request framework of the present invention has significant advantages: its ability to predict in advance enables open source projects to identify potential contributions earlier, thereby optimizing the management process of branches and pull requests. By accurately identifying high-value contributions, project maintainers can organize code reviews and coordinate development tasks more efficiently, thereby improving the collaborative efficiency of the project. In addition, because the framework is scalable, it can be applied to open source projects of different sizes and types, whether small independent projects or large and complex projects, and can effectively improve development and management efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1 is a flow chart of a method according to an embodiment of the present invention; Figure 2 The figure is a logic principle diagram of the method according to an embodiment of the present invention. DETAILED DESCRIPTION

[0025] The present invention is further explained below in conjunction with specific embodiments. It should be understood that these embodiments are only used to illustrate the present invention and are not used to limit the scope of the present invention. After reading the present invention, various equivalent forms of modifications to the present invention by those skilled in the art all fall within the scope defined by the claims attached to this application.

[0026] The hardware environment required for implementing the method of the embodiment of the present invention includes: a router or switch that can normally access the wide area network, and a computer that can be used normally. The software environment is: Python 3.10.

[0027] like Figure 1-2As shown, a method for predicting pull requests for open source software projects based on a deep learning model of the present invention comprises the following steps: Modeling the statistical screening process of copy behavior of open source projects and a pull request prediction framework for open source software projects based on deep learning models.

[0028] Among them, in the clustering step of modeling the work behavior process of open source projects, the pull request process of the open source copy is modeled based on the statistical process of key variables, and the comprehensive characteristics of the text and code submitted by the copy are modeled using a deep feature model; finally, the statistical screening model and the deep feature model are used in combination to predict the potential lost contributions in the open source software, and based on the prediction results, further reminders and warnings are given for contributions that are potentially worthy of merging into the main repository.

[0029] Step 1: Obtain the required replica behavior stream data from the open source project. Assume that data of N open source projects are obtained from the open source software repository. The set Z represents all open source projects, where Z = {z1, z2, …zi, …,zN}, i = 1, …, N, where N is the number of open source projects and zi represents the i-th open source project in the obtained data set. Step 2: Get the replica work records of all open source projects in set Z, sort all the replica work data by time and store them in database W (such as Oracle, MongoDB, etc.); Step 3: Get data from the workflow database W, for the jth record wij of the i-th project in W. Perform data cleaning on each replica modification record to remove invalid or duplicate pull requests. Perform text processing on each replica submission file, including word segmentation, stop word removal, and stem extraction of the submission information. Finally, the set of all replica modification sequences is S.

[0030] Step 4: Statistical analysis of replica modifications in open source software to generate a normative statistical parameter set P, and filter replica modifications based on this set. First, collect submission records related to replicas from the version control system, including code change logs, timestamps, submitter information and other data. For these data, statistical key indicators are calculated, such as the increase or decrease in the number of lines of code modification, submission frequency, and the time interval between submissions. By calculating the pull jump ratio (defined as the ratio of the amount of changes from the last pull to the current submission to the total amount of changes) and the pull submission ratio (defined as the ratio of the number of submissions successfully converted to pull requests to the total number of submissions), key features reflecting collaborative behavior are extracted. Based on these statistical results, reasonable thresholds are set for preliminary screening, such as filtering out submissions with high-frequency invalid modifications or inefficient collaboration.

[0031] Step 4.1: In practice, the modification sequence S of all replicas is used as the model input, and the screening model is used to classify and prioritize the submission records to extract the submission set with potential pull request value. In order to optimize the model effect, the input data can be feature normalized and dimensionally reduced, and the parameters of the screening model can be tuned through cross-validation. Finally, the filtered submission set can be used as the input of the subsequent deep model to improve the accuracy and efficiency of potential pull request identification.

[0032] Step 5: Model the text and code modification information of open source software through a deep model, which is called a deep feature model M. First, collect relevant text and code modification data from the version control system, including submission information Message and code difference Code Diff data, and clean and preprocess them to remove invalid changes and noise data. Then, extract text features (such as TF-IDF and word vectors) and code features (such as syntax tree representation, code complexity, and call relationship graph), and combine these features through feature fusion technology to form a comprehensive feature set. On this basis, design and implement a set of recognition modules based on convolutional networks. By optimizing the number of layers and feature fusion methods (such as weighted average, attention mechanism, etc.), ensure that the network can efficiently capture the semantic associations and structural patterns between text and code, so as to achieve accurate identification of potential pull requests.

[0033] Step 6: Apply the combined filter obtained in step 4 and the deep feature model trained in step 5 to actual open source projects, and predict the quality and possibility of merging pull requests by analyzing code modifications and submitted text. Use a modular integration framework to embed the model into the continuous integration process to achieve automated evaluation and real-time feedback. By collecting feedback after merging, continuously optimize the model's training data set and algorithm to improve its applicability and prediction accuracy for different projects. At the same time, adjust the model parameters in a timely manner through performance monitoring to ensure its efficiency and stability in the production environment.

[0034] When applying the deep learning model-based open source software project pull request prediction framework disclosed in the present invention, first, it is necessary to collect a certain number of behavioral event records of open source projects, including code submissions, pull requests, and related comment content. Then, these behavioral events are modeled using a deep feature model to capture potential collaboration patterns and code modification trends in the project. Then, by predicting pull requests, efficient and inefficient collaboration patterns in the project are identified.

[0035] A typical application scenario of the present invention is to provide prediction and evaluation services for certain open source projects. For example, for an open source project that is gradually increasing in scale and faces a large number of development iteration requirements, the method can be used to analyze historical pull requests and project collaboration modes to evaluate the project's organization and collaboration efficiency. At the same time, based on the prediction results, template projects with efficient collaboration are provided for comparison to help the project team optimize the current development process. By referring to these efficient collaboration modes, ongoing pull requests and event processing can be effectively guided to avoid development bottlenecks caused by inefficient communication and collaboration.

[0036] In the embodiment, the above-mentioned step 1 obtains the required replica behavior process data from the open source platform, the data of each project obtained meets the data volume scale, and the obtained replica modification information is filtered and integrated, and the final process data includes project developers, replica development code and text and other information.

[0037] In the step 2, for each open source project Zi in the set Z, all copy behavior process records contained in each open source project are obtained, and stored in the database W after being sorted by time.

[0038] In step 3, data preprocessing is performed on each replica behavior flow record wij to remove irrelevant redundant information and retain only the specific description of the behavior, i.e., text modification, participants, code modification, modification time and other relevant necessary information. Finally, the set of all replica modification sequences is obtained, which is called the total replica modification sequence S.

[0039] The above step 4 specifically includes Step 4.1: From the replica workflow database W, define four key statistical parameters to obtain a normative statistical parameter set P. The four key statistical parameters for each project replica include: the number of pull requests created by each Fork; the number of commits included in each pull request; the number of skipped commits; the proportion of skipped commits. By analyzing the submission records of open source projects, the specific values ​​of the above parameters are calculated to provide key parameters for statistical screening modeling.

[0040] Step 4.2: Based on the statistical parameter P obtained in step 4.1, a statistical screening process is designed to screen the appropriate set of commits to build pull requests. In this process, multiple parameters are set, including the maximum number of commits and the maximum number of skipped commits, to balance the build efficiency and coverage, ensuring that the built pull request combination is both efficient and fully covers possible commits.

[0041] Step 4.3: Use the conclusions of steps 4.1 and 4.2 to filter the submission sets of all replicas to obtain the submission sets of replicas that conform to the TF model. Take out the behavior record data of the filtered submission set of replicas, that is, the sequence sij. Since the replica modification records are arranged in chronological order, each replica behavior contains the following triple information: (r, t, c), where r is the developer mark of the behavior; t is the label of the modification; and c is the detailed content of the modification.

[0042] The above step 5 specifically includes Step 5.1: Extract relevant commit records from the triples (r, t, c) obtained in step 4.3, including commit messages and code differences. Perform cleaning operations such as word segmentation, stop word filtering, and word form restoration on the commit messages to remove noise information; for code differences, remove meaningless changes (such as comment modifications and format adjustments), and parse the code structure into a syntax tree structure for easy analysis. Finally, align the text with the code data to form a one-to-one corresponding cleaned feature data set.

[0043] Step 5.2: According to step 5.1, in the model prediction process, a given potential pull request consists of a combination of several submissions, and its prediction task is modeled as a binary classification problem. For each potential PR combination, feature extraction is performed separately for the content feature Xc and statistical feature Xs. The content feature Xc contains the submission message and code difference. After being extracted by the pre-trained large language model, a representation vector with a dimension of 768 is obtained. In order to align the representation vector with the statistical feature dimension, the representation vector is reduced to 32 dimensions through a standard convolution module. The statistical feature Xs is directly encoded into a 32-dimensional feature representation.

[0044] Step 5.3: According to step 5.2, we get the vector representations Xc and Xs of the two features, align them and concatenate them column-wise to form a comprehensive feature Z=[Xc, Xs] with a dimension of 64. The comprehensive feature is input into a 64-dimensional perceptron module to complete feature fusion. The fused feature is input into the fully connected layer to get the prediction output.

[0045] The above step 6 specifically includes the following steps: Step 6.1: Use the trained deep feature model to predict actual open source projects. For each new code commit, the model generates a prediction result of the possible commit set becoming a pull request based on the code modifications and commit messages (i.e., content features) in the commit and statistical features.

[0046] Step 6.2: By providing feedback on incorrectly labeled or unsuccessfully predicted objects, analyzing these feedbacks helps identify the model’s error types and room for improvement. Early warnings are issued to main repositories that have not submitted contributions in a timely manner, indicating that contributions between these projects may be about to be lost.

Claims

1. A method for predicting pull requests for open source software projects based on a deep learning model, characterized in that: Obtain normative statistical parameters by counting the copy modifications in the open source software; use the statistical parameters for statistical screening modeling; Use deep models to deeply model the text and code modification information of open source software; Finally, the statistical screening model and deep feature model are used to predict the potential lost contributions in open source software; The above method specifically comprises the following steps: Step 1: Obtain the required replica behavior stream data from the open source project. Assume that data of N open source projects are obtained from the open source software repository. The set Z represents all open source projects, where Z = {z1, z2, …zi, …, zN}, i = 1, …, N, where N is the number of open source projects and zi represents the i-th open source project in the obtained data set. Step 2: Get the copy work records of all open source projects in the set Z, sort all the copy work record data by time and store them in the workflow database W; Step 3: Get data from the workflow database W. For the jth behavior flow record wij of the i-th project in W, perform data cleaning on each replica modification record to remove invalid or duplicate pull requests. Perform text processing on each replica submission file to obtain the set of all replica modification sequences, which is called the total replica modification sequence S. Step 4: Count the copy modifications in the open source software to obtain a normative statistical parameter set P; According to the parameter set P, set the thresholds of the pull jump ratio and the pull submission ratio to filter out qualified replica modifications; select a statistical screening method, establish a statistical screening model TF, and use the screening model to take the entire replica modification sequence S as input to extract the potential submission set; Step 5: Model the text and code modification information of the open source software through a deep model, which is called a deep feature model M; First, collect relevant text and code modification data from the version control system, including commit messages and code diff data; then extract text features and code features, and combine them to form a comprehensive feature set; based on a given set of features, design a set of convolutional network-based recognition modules that conform to their feature properties; Step 6: Apply the statistical screening model TF and the trained deep feature model to actual open source projects, make predictions on pull requests based on code modifications and submitted text, and collect feedback information to continuously iterate and improve the performance and applicability of the model.

2. The method for predicting pull requests for open source software projects based on a deep learning model according to claim 1, characterized in that: The step 1 obtains the required replica behavior process data from the open source platform, obtains data for each project that meets the data volume scale, and filters and integrates the obtained replica modification information. The final process data includes project developers, replica development codes and text information.

3. The method for predicting pull requests for open source software projects based on a deep learning model according to claim 1, characterized in that: In step 2, for each open source project Zi in the set Z, all copy behavior process records contained in each open source project are obtained, and stored in the workflow database W after being sorted by time.

4. The method for predicting pull requests for open source software projects based on a deep learning model according to claim 1, characterized in that: In step 3, data preprocessing is performed on each replica behavior process record wij to remove irrelevant redundant information and retain only the specific description of the behavior, i.e., text modification, participant, code modification, and modification time; the set of all replica modification sequences is obtained, which is called the total replica modification sequence S.

5. The method for predicting pull requests for open source software projects based on a deep learning model according to claim 1, characterized in that: Step 4 specifically includes: Step 4.1: From the replica workflow database W, four key statistical parameters are defined to obtain a normative statistical parameter set P; the four key statistical parameters of each project replica wij include: the number of pull requests created by each Fork; the number of commits included in each pull request; the number of skipped commits; the proportion of skipped commits; by analyzing the submission records of the open source project, the specific values ​​of the above key statistical parameters are calculated to provide key parameters for statistical screening modeling; Step 4.2: Based on the statistical parameter set P obtained in step 4.1, a statistical screening process is designed to screen the required submission set to build the pull request; in the statistical screening process of the entire submission set, multiple parameters are set, including the maximum number of submissions and the maximum number of skipped submissions; Step 4.3: Filter the submission set of all replicas to obtain the behavior record data in the filtered replica submission, that is, the sequence sij; since the replica modification records are arranged in chronological order, each replica behavior contains the following triple information: (r, t, c), where r is the developer mark of the behavior; t is the label of the modification; c is the detailed content of the modification.

6. The method for predicting pull requests for open source software projects based on a deep learning model according to claim 5, characterized in that: Step 5 specifically includes: Step 5.1: Extract relevant commit records from the triple (r, t, c), including commit message and code difference. Clean the commit message to remove noise information; remove meaningless changes from code differences, and parse the code structure into a syntax tree structure; finally, align the text with the code data to form a one-to-one cleaned feature data set; Step 5.2: In the model prediction process, a given potential pull request consists of a combination of several commits, and its prediction task is modeled as a binary classification problem; for each potential PR combination, feature extraction is performed separately for content features Xc and statistical features Xs; the content features Xc contain commit messages and code differences, and are extracted by the pre-trained large language model to obtain a representation vector; in order to align the representation vector with the statistical feature dimension, the representation vector is reduced in dimension through a standard convolution module; the statistical features Xs are directly encoded into the reduced-dimensional feature representation; Step 5.3: According to step 5.2, we get the vector representations Xc and Xs of the two features, align them and concatenate them column-wise to form a comprehensive feature Z = [Xc, Xs]. After the comprehensive feature is input into a perceptron module to complete feature fusion, the fused feature is input into the fully connected layer to get the predicted output.

7. The method for predicting pull requests for open source software projects based on a deep learning model according to claim 1, characterized in that: The above step 6 specifically includes the following steps: Step 6.1: Use the trained deep feature model to predict actual open source projects. For each new code commit, the model generates a prediction result of the possible commit set becoming a pull request based on the code modifications and commit messages in the commit and statistical features. Step 6.2: Analyze the feedback of incorrectly labeled or unsuccessfully predicted objects to help identify the model's error types and room for improvement; issue early warnings to main repositories where contributions have not been submitted in a timely manner, indicating that contributions between these projects may be about to be lost.

Images