Developer community division and project recommendation method for open source software project

Abstract

The invention belongs to the technical field of software engineering, deep learning and recommendation system crossing, and discloses an open source software project oriented developer community division and project recommendation method. In combination with context-aware graph neural network modeling and a dynamic density clustering technology, accurate community division of a developer collaborative network is realized, and personalized open source project recommendation is provided for a user. The method can effectively capture a complex interaction mode between a developer and a project, improves the intelligent level of a community discovery and recommendation system, and is of great significance to promotion of technology sharing and optimization of development resource configuration.

Description

Technical Field

[0001] The present invention belongs to the interdisciplinary field of software engineering, deep learning, and recommendation systems, and specifically relates to a method for developer community segmentation and project recommendation for open source software projects. The method is based on heterogeneous data modeling and dynamic community segmentation for open source software developer collaborative network analysis and project recommendation, and is particularly suitable for intelligent identification of developer communities and personalized project recommendation scenarios on the GitHub open source platform. Background Art

[0002] In the open source software development ecosystem, developers form a complex collaborative network through code submissions, problem-solving collaboration, and other activities. Accurately segmenting developer communities and enabling targeted project recommendations are crucial for promoting technology sharing and optimizing development resource allocation.

[0003] Existing methods for community segmentation primarily calculate similarity based on static features, which suffer from two limitations: First, traditional collaborative filtering methods ignore the temporal characteristics of developer behavior and multi-hop interactions, resulting in coarse-grained community segmentation. Second, existing graph neural network models fail to effectively distinguish the importance of different interactions when dealing with heterogeneous meta-paths. Regarding recommendation systems, current mainstream approaches, such as those based on matrix factorization, only utilize binary user-project relationships and are unable to model the indirect connections formed by developers through submission records. While meta-path-based graph embedding methods can capture multi-hop semantics, their fixed weight allocation mechanism makes them difficult to adapt to diverse collaboration patterns. Furthermore, traditional clustering algorithms require a preset number of communities and are unable to adapt to the dynamic nature of open source community size, resulting in recommendations that are insufficiently aligned with developers' real-time interests. Therefore, a method for developer community segmentation and project recommendation for open source software projects is urgently needed to address the limitations of traditional approaches in modeling complex collaboration patterns and the limited recommendation accuracy caused by rigid community boundaries. Summary of the Invention

[0004] The purpose of this invention is to provide a method for segmenting developer communities and recommending projects for open source software projects. By integrating multi-dimensional open source project data with user behavior characteristics, combined with context-aware graph neural network modeling and dynamic density clustering techniques, this method achieves precise community segmentation of developer collaboration networks and provides users with personalized open source project recommendations. This method can effectively capture the complex interaction patterns between developers and projects, enhancing the intelligence of community discovery and recommendation systems, and is of great significance for promoting technology sharing and optimizing development resource allocation.

[0005] To achieve the above object, the technical solution adopted by the present invention is:

[0006] A method for dividing developer communities and recommending projects for open source software projects, comprising:

[0007] Extract project data, commit record data, and user data of open source software projects;

[0008] Clean and standardize the extracted project data, commit record data, and user data. Based on the commit record data's title content, the commit record data is divided into three types of submissions: document modification submissions, bug fix submissions, and functional submissions.

[0009] Map project data to vector space to obtain project embedding vectors, map user data to vector space to obtain user embedding vectors, and calculate the user-project edge weights of the interaction edges consisting of user data and project data based on the commit record data of the three commit categories;

[0010] Sample 1st to 3rd order paths for each user data and item data respectively, and aggregate 1st to 3rd order paths based on user embedding vector, item embedding vector and user-item edge weight to obtain aggregated path user embedding vector and aggregated path item embedding vector;

[0011] The distance between two users is measured based on the user embedding vector of each user's aggregated path, and the developer community topology structure is obtained by clustering based on the distance between the two users;

[0012] Locate the developer community to which the target user belongs, extract the aggregated path item embedding vectors of all projects in the developer community, calculate the similarity between the user's aggregated path user embedding vector and the extracted aggregated path item embedding vector, and output the item recommendation results based on the similarity.

[0013] Several optional methods are also provided below, but they are not intended to be additional limitations on the above-mentioned overall solution. They are merely further supplements or optimizations. Under the premise that there are no technical or logical contradictions, each optional method can be combined separately for the above-mentioned overall solution, or multiple optional methods can be combined.

[0014] Preferably, the extracting of project data, commit record data, and user data of an open source software project includes:

[0015] Obtain an initial project path list of open source software projects on the open source software platform;

[0016] Traversing the initial project path list, extracting project data corresponding to the open source software project according to the initial project path, wherein the project data includes programming language, number of stars, number of copies, number of open issues, and project description;

[0017] Extract all commit record data in the main branch of the open source software project, including commit date, commit author, and title;

[0018] Extract the submitting authors from all commit record data and deduplicate them. Then extract user data based on the deduplicated submitting authors. The user data includes region, company, email address, number of public repositories, number of followers, number of followers, and total number of submissions.

[0019] Preferably, the cleaning and standardization of the extracted project data, commit record data, and user data includes:

[0020] The cleaning process includes: for project data, if any of the programming language and project description attributes are empty, the project data will be removed, and the related commit record data will also be removed; for commit record data, if any of the submission date, submission author, and title attributes are empty, the commit record data will also be removed; for user data, if any of the company, email address, number of public repositories, number of followers, number of followers, and total number of commits attributes are empty, the user data will be removed, and the related commit record data will also be removed;

[0021] The standardization process includes: for project data, first fill in missing values, then perform one-hot encoding on the programming language, normalize the number of stars, copies, and open issues, and encode the project description using the BERT model to generate a semantic vector; for user data, normalize the number of public repositories, the number of followers, the number of followers, and the total number of submissions; for regional attributes, combine the email and company attributes to determine the user's country, and modify the region, company, and email fields to the one-hot encoding of the user's country.

[0022] Preferably, the commit record data is divided into three submission categories according to the title content of the commit record data: document modification submission, bug modification submission, and functional submission, including:

[0023] If the title of the commit record data contains one or more of the keywords "doc", "docs", "document", "documentation", and "readme", the submission category of the commit record data is classified as a document modification submission;

[0024] Alternatively, if the title of the commit record data contains one or more of the keywords "fix", "bug", "issue", "problem", and "error", the commit record data is classified as a bug fix commit;

[0025] Alternatively, if the title of the commit record data contains one or more of the keywords "feature", "add", "implement", "support" and "enhance", the submission category of the commit record data is classified as a functional submission.

[0026] Preferably, the calculation of the user-project edge weight of the interaction edge consisting of user data and project data based on the commit record data of the three submission categories includes:

[0027] Based on each commit record data related to the user and the project, three features are extracted. The extraction process is as follows:

[0028] (1) Commit type feature: Generate a 3D one-hot encoding vector based on the commit category to which the commit record data belongs;

[0029] (2) Time decay characteristics:

[0030] T=e -λ·△t

[0031] Where T represents the time decay feature, λ = 0.1, and △t represents the number of days between the last submission date in the current submission category of the commit record data and the current time;

[0032] (3) Behavior frequency feature: The total number of submissions of a category of submissions by a user on a project is normalized as the behavior frequency feature;

[0033] The commit type feature, time decay feature, and behavior frequency feature extracted from a commit record are concatenated to form an edge feature vector. Based on the classification results of the commit record data, the edge feature vectors belonging to the same commit category are concatenated to form the feature representation of the user-project edge under the corresponding commit category.

[0034] The user embedding vector, item embedding vector and feature representation of the corresponding submission category under a user-item edge are concatenated into a combined vector. This vector is then processed through three independent fully connected layers and the LeakyReLU activation function is applied to obtain the raw attention score for each submission category.

[0035] The original attention scores of the three submission categories are softmax normalized to obtain the weight coefficient of each submission category. The weight coefficient of each submission category is weighted and summed with the basic weight parameter of each submission category to obtain the user-item edge weight.

[0036] Preferably, sampling 1st to 3rd order paths for each user data and item data respectively, and aggregating the 1st to 3rd order paths based on the user embedding vector, the item embedding vector, and the user-item edge weight to obtain the aggregated path user embedding vector and the aggregated path item embedding vector, comprises:

[0037] For each user data or item data, a preset number of 1st to 3rd order paths are sampled, and an initial vector for each path is generated based on the user embedding vector, item embedding vector, and user-item edge weight;

[0038] Use gated recurrent units to process the initial vector of each path to obtain the path feature vector;

[0039] The average value of all user-item edge weights in each path is taken as the path weight. The corresponding path feature vector is weighted using the path weight. The weighted path feature vectors are concatenated in the order of 1st, 2nd, and 3rd order and then layer-normalized to obtain the final output aggregated path user embedding vector or aggregated path item embedding vector.

[0040] Preferably, sampling a preset number of 1st to 3rd order paths for each user data or item data, and generating an initial vector for each path based on the user embedding vector, the item embedding vector, and the user-item edge weight, comprises:

[0041] Batch sampling is performed for the 1st to 3rd order paths of each user node u. The specific sampling method is:

[0042] (1) The first-order path sampling is the collaborative relationship of "user u→project p", and the user embedding vector h is concatenated. u , item embedding vector h p , the user-item edge weight of the interaction edge ω (u,p) , generate the first-order path initial vector x1=[h u ;h p ;ω (u,p) ];

[0043] (2) The second-order path sampling is the collaborative relationship of "user u → project p → user u'", and the user embedding vector h of user u is concatenated. u , user embedding vector h of user u′ u′ , the item embedding vector h of item p p , the user-item edge weight ω of the interaction edge between user u and item p (u,p), the user-item edge weight ω of the interaction edge between user u′ and item p (u′,p) , generate the second-order path initial vector x2=[h u ;h p ;h u′ ;ω (u,p) ;ω (u′,p) ];

[0044] (3) The third-order path sampling is the associated transfer mode of “user u→item p→user u′→item p′”, and the user embedding vector h of user u is concatenated. u , user embedding vector h of user u′ u′ , the item embedding vector h of item p p , the item embedding vector h of item p′ p′ , the user-item edge weight ω of the interaction edge between user u and item p (u,p) , the user-item edge weight ω of the interaction edge between user u′ and item p (u′,p) , the user-item edge weight ω of the interaction edge between user u′ and item p′ (u′,p′) , generate the initial vector x3 of the third-order path of user node u = [h u ;h p ;h u′ ;h p′ ;ω (u,p) ;ω (u′,p) ;ω (u′,p′) ];

[0045] Batch sampling is performed for the 1st to 3rd order paths of each project node p. The specific sampling method is as follows:

[0046] (1) The first-order path sampling is the collaborative relationship of "project p → user u", and the user embedding vector h is concatenated. u , item embedding vector h p , the user-item edge weight of the interaction edge ω (u,p) , generate the first-order path initial vector y of the project node p u =[h p ;h u ;ω (u,p) ];

[0047] (2) The second-order path sampling is the collaborative relationship of "project p → user u → project p'", and the user embedding vector h of user u is concatenated. u , the item embedding vector h of item p′ p′ , the item embedding vector h of item p p , the user-item edge weight ω of the interaction edge between user u and item p (u,p) , the user-item edge weight ω of the interaction edge between user u and item p′ (u,p′), generate the initial vector y2 of the second-order path of the project node p = [h p ;h u ;h p′ ;ω (u,p) ;ω (u,p′) ];

[0048] (3) The third-order path sampling is the associated transmission mode of "item p→user u→item p′→user u′", and the user embedding vector h of user u is concatenated. u , user embedding vector h of user u′ u′ , the item embedding vector h of item p p , the item embedding vector h of item p′ p′ , the user-item edge weight ω of the interaction edge between user u and item p (u,p) , the user-item edge weight ω of the interaction edge between user u and item p′ (u,p′) , the user-item edge weight ω of the interaction edge between user u′ and item p′ (i′,p′) , generate the initial vector x3 of the third-order path of the project node p = [h p ;h i ;h p′ ;h u′ ;ω (u,p) ;ω (u,p′) ;ω (u′,p′) ].

[0049] Preferably, clustering based on the distance between two users to obtain the developer community topology structure includes:

[0050] For user u i , if the neighborhood of ε contains i If the number of users whose distance does not exceed ε is not less than the minimum number of core points, then user u i is a core user; otherwise, user u i Not for core users;

[0051] If user u j In the core user u i If user u is in the ε neighborhood of j For core users u i The density of users can be reached;

[0052] Traverse all users and extract core users. For each core user, find all density-reachable users and form an initial community with the core user and the density-reachable users belonging to the same core user. Repeat the traversal of the communities. If two communities have common core users or density-reachable users, merge them into the same community. After the community is merged, users who do not belong to any community are treated as noise points and removed. Finally, output the community as a developer community to form a developer community.

[0053] Preferably, the outputting of project recommendation results according to similarity includes:

[0054] The similarity is normalized by the Softmax function to generate a probabilistic score and sort it. The projects that the user has participated in are filtered and the Top-N recommendation list is output based on the filtered sorting as the project recommendation result.

[0055] The method for dividing developer communities and recommending projects for open source software projects provided by the present invention has the following advantages compared to the prior art:

[0056] (1) Deep semantic fusion: By integrating multimodal data such as project description text and developer collaboration behavior, combined with contextual semantic analysis and dynamic feature encoding, it accurately captures developers' technical preferences and project domain characteristics, breaking through the traditional method's single reliance on structured data and significantly improving the rationality of community division.

[0057] (2) Adaptive community discovery mechanism: It uses density clustering technology to dynamically identify the natural boundaries of developer groups without presetting the number or size of communities. It can identify both small technical teams that work closely together and large open source communities that are loosely connected, adapting to the needs of projects at different development stages.

[0058] (3) Personalized recommendations and diversity assurance: Through collaborative analysis of behavioral patterns within the developer community, the recommendation results maintain the relevance of the technology stack and avoid homogenization through a diversity constraint mechanism, ensuring that developers can access core field projects while exploring emerging technology directions. BRIEF DESCRIPTION OF THE DRAWINGS

[0059] Figure 1 A flowchart of the method for dividing developer communities and recommending projects for open source software projects according to the present invention;

[0060] Figure 2 This is a flowchart of the present invention's training based on the context path graph neural network model. DETAILED DESCRIPTION

[0061] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.

[0062] It should be noted that when a component is referred to as being “connected” to another component, it may be directly connected to the other component or there may be a component in the middle; when a component is referred to as being “fixed” to another component, it may be directly fixed to the other component or there may be a component in the middle.

[0063] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art of the present invention. The terms used in the specification of the present invention herein are only for the purpose of describing specific embodiments and are not intended to limit the present invention.

[0064] In order to overcome the defects of the existing technology, this embodiment provides a developer community division and project recommendation method for open source software projects, such as Figure 1 As shown, the specific steps include:

[0065] Step 1: Extract project data, commit record data, and user data of open source software projects.

[0066] Step 1-1: Use the Github API (https: / / api.github.com / search / repositories?q=stars:>100+created:{2014-07-01}..{2024-07-01}&page={page}&per_page=100) to retrieve high-quality open source software projects from the GitHub open source software platform. Set the filter condition to a star value greater than 100 and the project's creation time to obtain an initial project path list. The initial project path in the initial project path list is in the format of username / repository.

[0067] Step 1-2: Traverse the initial project path list and use the GitHub API (https: / / api.github.com / repos / {owner} / {repo}) to extract the project data (programming language, number of stars, number of copies, number of open issues, project description) of the corresponding open source software project based on the initial project path. Store the extracted project data in the form of a JSON object in the project.json file.

[0068] After extracting the project data, use the GitHub API (https: / / api.github.com / repos / {owner} / {repo} / commits?sha=main) to extract all the commit record data (commit date, commit author, title) in the main branch of the open source software project, and save the extracted commit record data in the form of a JSON object in the commits.json file.

[0069] Extract the commit author from all commit records and deduplicate them. Then use the GitHub API (https: / / api.github.com / users / {username}) to extract user data (region, company, email address, number of public repositories, number of followers, number of followers, and total number of commits). The total number of commits is the number of commits associated with the user in the database. The extracted user data is stored in the user.json file as a JSON object. The format of a JSON object in the user.json file is as follows:

[0070] {

[0071] "location":"xxx",

[0072] "company":"xxx",

[0073]

[0074] Once the traversal is completed, the loop continues until all open source software projects in the initial project path list are extracted. In this embodiment, project data, commit record data and user data are stored in a json file to facilitate subsequent data processing.

[0075] Step 2: Clean and standardize the raw data (project data, commit records, and user data): remove duplicate records, fill missing values, and normalize numerical features. Project descriptions are encoded using the BERT model to generate semantic vectors.

[0076] Step 2-1: Traverse the local project.json, local commits.json, and local user.json files. For project data, if any of the programming language or project description attributes is empty, the project data will be removed, along with the associated commit records. For commit records, if any of the submission date, submission author, or title attributes is empty, the commit record will be removed. For user data, if any of the company, email address, number of public repositories, number of followers, number of followers, or total number of commits is empty, the user data will be removed, along with the associated commit records. A project has one project data item and multiple corresponding commit records. If a project data item is removed, all commit records under that project will be removed. Users should understand this.

[0077] Step 2-2: Traverse the local project.json file and first fill in missing values ​​(use the mean value for the number of stars, copies, and open issues). Then, perform one-hot encoding on the programming languages ​​listed in Table 1. If other programming languages ​​are available, use a similar method to perform one-hot encoding.

[0078] Table 1 Programming language One-Hot encoding correspondence table

[0079] programming language One-Hot Encoding C++ [1,0,0,0,0,0] Go [0,1,0,0,0,0] Java [0,0,1,0,0,0] JavaScript [0,0,0,1,0,0] Python [0,0,0,0,1,0] C# [0,0,0,0,0,1]

[0080] The number of stars, copies, and open issues are normalized using formula (1).

[0081]

[0082] Taking the copy number as an example, where C p Represents the value after normalization of the project copy number, C now Indicates the number of copies of a json object in the project.json file, C min Indicates the minimum number of project copies in all json objects in the local project.json file, C max Indicates the maximum number of project copies among all JSON objects in the local project.json file.

[0083] The project description is encoded using the BERT model to generate a semantic vector. A pretrained BERT model is selected and the project description (e.g., "Python") is formatted to BERT's standard input: the [CLS] tag is added before the text and the [SEP] tag is added at the end. For example, the input becomes [CLS]Python[SEP]. The BERT model's tokenizer is used to split the text into subwords (e.g., "Python" is split into ["py", "##thon"]) and convert them into a sequence of IDs. The ID sequence is then fed into the BERT model, and the vector corresponding to the [CLS] tag in the last hidden state layer is extracted as the semantic representation of the entire text. Finally, the sum of the squares of the generated vector elements is calculated, and the L2 norm is obtained. Each element is then divided by this norm to generate the final encoded semantic vector.

[0084] Traverse the local commits.json file and classify it into three categories based on the commit title content: document modification commits, bug fix commits, and functional commits. The classification rules are as follows:

[0085] A. Modify the document submission: The title must contain keywords such as "doc", "docs", "document", "documentation", "readme", etc.

[0086] B. Bug fix submission: The title should contain keywords such as "fix", "bug", "issue", "problem", "error", etc.

[0087] C. Functional submission: The title should contain keywords such as "feature", "add", "implement", "support", "enhance", etc.

[0088] Traverse the local user.json file and normalize the number of public repositories, number of followers, number of followers, and total number of submissions (for example, using formula (1)). For the region attribute, combine the email and company attributes to determine the user's country, and modify the region, company, and email fields to the one-hot encoding of the user's country. The specific process is as follows:

[0089] A. For users whose user regions are not empty, first create a dictionary, use the crawler script to obtain the corresponding relationship between the country and the region of common countries and store it in the dictionary, and then directly convert the non-empty user region into the corresponding country;

[0090] B. For users whose region is left blank, a crawler script is used to obtain the countries corresponding to the top 100 common email suffixes worldwide and the countries where the top 500 IT companies are headquartered. The user's email address and company are then searched. If the countries corresponding to the email address and company are the same, the user's region is directly converted to the corresponding country. If the countries corresponding to the email address and company are different, the country field is marked as unknown.

[0091] Step 3: Train the neural network model based on the context path graph, such as Figure 2 The following steps are shown.

[0092] Step 3-1. Embedding conversion: Through a heterogeneous feature encoder, the original features of the two entities, project data and user data, are mapped to a unified vector space. For project nodes (considering a project data as a node), the one-hot encoding vector of the programming language, the normalized number of stars, the number of copies, the number of open issues, and the semantic vector of the project description generated by encoding the BERT model and L2 normalized are first used as input features; then, a multi-layer fully connected neural network is used to compress and convert these input features into a vector space to obtain the project embedding vector. For user nodes (considering a user data as a node), the one-hot encoding of the user's country, the normalized number of public repositories, the number of followers, the number of followers, and the total number of submissions are used as input features; similarly, a multi-layer fully connected neural network is used to convert these input features into the same vector space as the project node to obtain the user embedding vector.

[0093] Step 3-2: Calculate edge weights based on the category, temporal decay factor, and behavior frequency of commit record data.

[0094] Step 3-2-1, Multi-head feature encoding: For each user-project edge (an edge is constructed between the project data of a project and the user data of a user as a user-project edge), three features are extracted based on all commit records related to the user and the project. One commit record is extracted to obtain an edge feature vector:

[0095] (1) Submission type feature: Based on the classification result of the commit record data (document modification submission, bug fix submission, functional submission) in step 2-2, a 3D one-hot encoding vector is generated. For example, if the classification result is document modification submission, the feature is [1, 0, 0].

[0096] (2) Time decay characteristics: Calculated using formula (2):

[0097] T=e -λ·△t (2)

[0098] Where T represents the time decay feature, λ = 0.1, and △t represents the number of days between the last submission date in the current submission category of the commit record data and the current time.

[0099] (3) Behavior frequency characteristics: Normalize the total number of submissions of a certain submission category by the user on the project.

[0100] The submission type feature, time decay feature, and behavior frequency feature extracted from a commit record data are concatenated to form an edge feature vector. According to the classification result of the commit record data, the edge feature vectors belonging to the same submission category are concatenated to form the feature representation f of the user-project edge under the corresponding submission category. edge If the current user-item edge has three submission categories, three feature representations are extracted from the user-item edge.

[0101] Step 3-2-2, attention score calculation: First, the user embedding vector, item embedding vector and feature representation of the corresponding submission category under a user-item edge are concatenated into a combined vector. Then, after processing through three independent fully connected layers, the LeakyReLU activation function is applied to obtain the raw attention score of each submission category, as shown in formula (3):

[0102]

[0103] Where k∈{1,2,3} represents the submission category (document modification submission, bug fix submission, functional submission), represents the trainable weight matrix for the k-th submission category, h u represents the user embedding vector of the user node, h p Item embedding vectors representing item nodes, The feature representation of the k-th submission category.

[0104] Step 3-2-3, User-item edge weight calculation: Perform softmax normalization on the original attention scores of the three submission categories calculated in step 3-2-2 to obtain the weight coefficient of each submission category, as shown in formula (4):

[0105]

[0106] The final user-item edge weight is ω=α1ω doc +α2ω bug +α3ω feat , where ω * The base weight parameters for each submission category generated for training.

[0107] Step 3-3: Multi-stage path aggregation to generate user embedding vectors and item embedding vectors after the aggregated path.

[0108] First, batch sampling is performed on the 1st to 3rd order path instances of each user node u. The specific sampling method is as follows:

[0109] (1) The first-order path samples the collaborative relationship of the form "user u→project p" and concatenates the user embedding vector h u , item embedding vector h p , the user-item edge weight of the interaction edge ω (u,p) , generate the first-order path initial vector x1=[h u ;h p ;ω (u,p) ];

[0110] (2) The second-order path sampling is a collaborative relationship of the form "user u → project p → user u'", and the user embedding vector h of user u is concatenated. u , user embedding vector h of user u′ u′ , the item embedding vector h of item p p , the user-item edge weight ω of the interaction edge between user u and item p (u,p) , the user-item edge weight ω of the interaction edge between user u′ and item p (u′,p) , generate the second-order path initial vector x2=[h u ;h p ;h u′ ;ω (u,p) ;ω (u′,p) ];

[0111] (3) The third-order path sampling is like the associated transfer mode of “user u→item p→user u′→item p′”, and the user embedding vector h of user u is concatenated. u , user embedding vector h of user u′ u′ , the item embedding vector h of item p p , the item embedding vector h of item p′ p′ , the user-item edge weight ω of the interaction edge between user u and item p (u,p) , the user-item edge weight ω of the interaction edge between user u′ and item p (u′,p) , the user-item edge weight ω of the interaction edge between user u′ and item p′ (u′,p′) , generate the initial vector x3 of the third-order path of user node u = [h u ;h p ;h u′ ;h p′ ;ω (u,p) ;ω (u′,p) ;ω (u′,p′) ].

[0112] During the sampling process, the number of samples for the 1st, 2nd, and 3rd order paths of a certain user node is set according to 4:2:1.

[0113] Then, a GRU (Gated Recurrent Unit) is used to process the initial vectors of the 1st, 2nd, and 3rd order paths of user node u. For multiple paths of a certain order, a weighted average of the hidden states is required, where the weight is the edge weight of the corresponding path. The GRU unit is updated according to the following formulas (5), (6), (7), and (8):

[0114] Reset gate: r t =σ(W r x t +U r h t-1 +b r )(5)

[0115] Update gate: z t =σ(W z x t +U z h t-1 +b z )(6)

[0116] Candidate hidden states:

[0117] Hide status update:

[0118] Among them, x t is the input of the current time step, h t-1 is the hidden state of the previous time step, W r 、U r 、W z 、U z , W, u are trainable weight matrices, b r 、b z , b is the bias vector.

[0119] The final output feature vector of each order GRU is recorded as h GRUx1 、h GRUx2 、h GRUx3 , which is the path feature vector.

[0120] Perform Hadamard product between the output feature vector of each order GRU and the path weight of the corresponding path to obtain h′ GRUx1 , h′ GRUx2 , h′ GRUx3 , where for the first-order path, the path weight w x1 is the user-item edge weight connecting user u and item p; for a 2nd-order path, the path weight wx2 is the average of the user-item edge weight connecting user u′ and item p and the user-item edge weight connecting user u and item p; for a third-order path, the path weight w x3 For user u′ and item p ′ The user-item edge weight of the connection is the average of the user-item edge weight connecting user u′ and item p, and the user-item edge weight connecting user u and item p.

[0121] The weighted feature matrices of each order are concatenated in the order of 1, 2, and 3 and then normalized layer by layer to obtain the final output aggregated path user embedding vector.

[0122] Secondly, batch sampling is performed on the 1st to 3rd order path instances of each project node p. The specific sampling method is as follows:

[0123] (1) The first-order path samples the collaborative relationship of the form "project p → user u" and concatenates the user embedding vector h u , item embedding vector h p , the user-item edge weight of the interaction edge ω (u,p) , generate the initial vector y1 of the first-order path of the project node p = [h p ;h u ;ω (u,p) ];

[0124] (2) The second-order path sampling is a collaborative relationship of the form "project p → user u → project p'", and the user embedding vector h of user u is concatenated. u , the item embedding vector h of item p′ p′ , the item embedding vector h of item p p , the user-item edge weight ω of the interaction edge between user u and item p (u,p) , the user-item edge weight ω of the interaction edge between user u and item p′ (u,p′) , generate the initial vector y2 of the second-order path of the project node p = [h p ;h u ;h p′ ;ω (u,p) ;ω (u,p′) ];

[0125] (3) The third-order path sampling is an association transfer mode of “item p → user u → item p′ → user u′”, and the user embedding vector h of user u is concatenated. u , user embedding vector h of user u′ u′ , the item embedding vector h of item p p , the item embedding vector h of item p′ p′ , the user-item edge weight ω of the interaction edge between user u and item p (u,p), the user-item edge weight ω of the interaction edge between user u and item p′ (u,p′) , the user-item edge weight ω of the interaction edge between user u′ and item p′ (u′,o′) , generate the initial vector x3 of the third-order path of the project node p = [h p ;h u ;h p′ ;h u′ ;ω (u,o) ;ω (u,p′) ;ω (u′,p′) ].

[0126] During the sampling process, the number of samples for the 1st, 2nd, and 3rd order paths of a certain project node is set according to 4:2:1.

[0127] Then, GRU is used to process the initial vectors of the 1st, 2nd, and 3rd order paths of the project node respectively. For multiple paths of a certain order, the hidden state needs to be weighted averaged, and the weight is the edge weight of the corresponding path. The GRU unit is updated according to the following formulas (9), (10), (11), and (12):

[0128] Reset gate: r t =σ(W r x t +U r h t-1 +b r )(9)

[0129] Update gate: z t =σ(W z x t +U z h t-1 +b z )(10)

[0130] Candidate hidden states:

[0131] Hide status update:

[0132] Among them, x t is the input of the current time step, h t-1 is the hidden state of the previous time step, W r 、U r 、W z 、U z , W, u are trainable weight matrices, b r 、b z , b is the bias vector.

[0133] The final output feature vector of each order GRU is recorded as h GRUy1 、h GRUy2 、hGRUy3 .

[0134] Perform Hadamard product between the output feature vector of each order GRU and the path weight of the corresponding path to obtain h′ GRUy1 , h′ GRUy2 , h′ GRUy3 , where for the first-order path, the path weight w y1 is the user-item edge weight connecting user u and item p; for a 2nd-order path, the path weight w y2 For user u and project p ′ The average of the user-item edge weight of the connection and the user-item edge weight of the connection between user u and item p; for a third-order path, the path weight w y3 For user u′ and item p ′ The user-item edge weight of the connection, user u and item p ′ The user-item edge weight of the connection, the average of the user-item edge weights connecting user u and item p.

[0135] The weighted feature matrices of each order are concatenated in the order of 1, 2, and 3 and then normalized layer by layer to obtain the final output of the aggregated path item embedding vector.

[0136] Step 4: Developer community division and project recommendation.

[0137] Step 4-1: Developer community division:

[0138] (1) Define the Euclidean distance between two points in the user embedding space as dist(u i ,u j )=||h i -h j ||2, where h i With h j Aggregate path user embedding vector for two different users;

[0139] (2) Define N ε (u i )={u j |dist(u i ,u j )≤ε}, that is, for user u i , the ε neighborhood contains all i For users whose distance does not exceed ε, ε is automatically determined based on the statistical characteristics of the user embedding space, preferably the median of the Euclidean distances of all users, or dynamically adjusted through k-distance curve inflection point detection to adapt to the distribution of developer collaboration density in open source communities of different sizes;

[0140] (3) If N ε (u i) is not less than the customized minimum core points MinPts (the default is 10), then u i For core users;

[0141] (4) If user u j In the core user u i In the ε neighborhood, it is called u j From u i Direct density can be reached, u j for u i The density of users can be reached;

[0142] (5) If there is a user chain u1→u2→...→u k , where each u i+1 From u i Direct density can be reached, then u k From u1 density can be reached, u k is the density of reachable users of u1.

[0143] Receive the aggregated path user embedding vector output in step 3, traverse all users, and extract the user that meets |N ε (u i )|≥MinPts core users; for each core user, recursively search all density-reachable users to form an initial community; if two communities have common core users or density-reachable users, they are merged into the same community; if non-core users belong to the ε neighborhood of a core user, they are included in the corresponding community, otherwise they are regarded as noise points; finally, the developer community topology structure is output.

[0144] Step 4-2, Project Recommendation: First, locate the developer community to which the target user (the user obtained in steps 1 and 2, whose relevant information is known) belongs. Extract the embedding vectors of all aggregated paths within the community to construct a candidate set. After calculating the correlation between the user and the candidate projects based on cosine similarity, specifically calculate the cosine similarity between the user's aggregated path embedding vector and the aggregated path embedding vector of the candidate projects. Normalize the cosine similarity using the Softmax function to generate a probabilistic score and sort it. Finally, filter the projects in which the user has participated and output a top-10 recommendation list. This method effectively captures complex interaction patterns, improves the rationality of community division and the accuracy of recommendations, adapts to the dynamic changes of open source communities, and promotes technology sharing and optimal resource allocation.

[0145] The technical features of the above-mentioned embodiments can be combined arbitrarily. In order to make the description concise, not all possible combinations of the technical features in the above-mentioned embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0146] The above-described embodiments merely illustrate several implementations of the present invention, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention. It should be noted that a person skilled in the art would be able to make numerous modifications and improvements without departing from the spirit of the present invention, all of which fall within the scope of protection of the present invention. Therefore, the scope of protection of the present invention shall be determined by the appended claims.

Claims

1. A method for dividing developer communities and recommending projects for open source software projects, characterized in that: The developer community division and project recommendation method for open source software projects include: Extract project data, commit record data, and user data of open source software projects; Clean and standardize the extracted project data, commit record data, and user data. Based on the commit record data's title content, the commit record data is divided into three types of submissions: document modification submissions, bug fix submissions, and functional submissions. Map project data to vector space to obtain project embedding vectors, map user data to vector space to obtain user embedding vectors, and calculate the user-project edge weights of the interaction edges consisting of user data and project data based on the commit record data of the three commit categories; Sample 1st to 3rd order paths for each user data and item data respectively, and aggregate 1st to 3rd order paths based on user embedding vector, item embedding vector and user-item edge weight to obtain aggregated path user embedding vector and aggregated path item embedding vector; The distance between two users is measured based on the user embedding vector of each user's aggregated path, and the developer community topology structure is obtained by clustering based on the distance between the two users; Locate the developer community to which the target user belongs, extract the aggregated path item embedding vectors of all projects in the developer community, calculate the similarity between the user's aggregated path user embedding vector and the extracted aggregated path item embedding vector, and output the item recommendation results based on the similarity.

2. The method for dividing developer communities and recommending projects for open source software projects according to claim 1, characterized in that: The extraction of project data, commit record data, and user data of open source software projects includes: Obtain an initial project path list of open source software projects on the open source software platform; Traversing the initial project path list, extracting project data corresponding to the open source software project according to the initial project path, wherein the project data includes programming language, number of stars, number of copies, number of open issues, and project description; Extract all commit record data in the main branch of the open source software project, including commit date, commit author, and title; Extract the submitting authors from all commit record data and deduplicate them. Then extract user data based on the deduplicated submitting authors. The user data includes region, company, email address, number of public repositories, number of followers, number of followers, and total number of submissions.

3. The method for dividing developer communities and recommending projects for open source software projects according to claim 2, characterized in that: The extracted project data, commit record data, and user data are cleaned and standardized, including: The cleaning process includes: for project data, if any of the programming language and project description attributes are empty, the project data will be removed, and the related commit record data will also be removed; for commit record data, if any of the submission date, submission author, and title attributes are empty, the commit record data will also be removed; for user data, if any of the company, email address, number of public repositories, number of followers, number of followers, and total number of commits attributes are empty, the user data will be removed, and the related commit record data will also be removed; The standardization process includes: for project data, first fill in missing values, then perform one-hot encoding on the programming language, normalize the number of stars, copies, and open issues, and encode the project description using the BERT model to generate a semantic vector; for user data, normalize the number of public repositories, the number of followers, the number of followers, and the total number of submissions; for regional attributes, combine the email and company attributes to determine the user's country, and modify the region, company, and email fields to the one-hot encoding of the user's country.

4. The method for dividing developer communities and recommending projects for open source software projects according to claim 1, characterized in that: According to the title content of the commit record data, the commit record data is divided into three submission categories: document modification submission, bug fix submission and functional submission, including: If the title of the commit record data contains one or more of the keywords "doc", "docs", "document", "documentation", and "readme", the submission category of the commit record data is classified as a document modification submission; Alternatively, if the title of the commit record data contains one or more of the keywords "fix", "bug", "issue", "problem", and "error", the submission category of the commit record data is classified as a bug fix submission; Alternatively, if the title of the commit record data contains one or more of the keywords "feature", "add", "implement", "support" and "enhance", the submission category of the commit record data is classified as a functional submission.

5. The method for dividing developer communities and recommending projects for open source software projects according to claim 1, characterized in that: The calculation of the user-project edge weight of the interaction edge consisting of user data and project data based on the commit record data of the three submission categories includes: Based on each commit record data related to the user and the project, three features are extracted. The extraction process is as follows: (1) Commit type feature: Generate a 3D one-hot encoding vector based on the commit category to which the commit record data belongs; (2) Time decay characteristics: T=e -λ·△t Where T represents the time decay feature, λ = 0.1, and △t represents the number of days between the last submission date in the current submission category of the commit record data and the current time; (3) Behavior frequency feature: The total number of submissions of a category of submissions by a user on a project is normalized as the behavior frequency feature; The commit type feature, time decay feature, and behavior frequency feature extracted from a commit record are concatenated to form an edge feature vector. Based on the classification results of the commit record data, the edge feature vectors belonging to the same commit category are concatenated to form the feature representation of the user-project edge under the corresponding commit category. The user embedding vector, item embedding vector and feature representation of the corresponding submission category under a user-item edge are concatenated into a combined vector. This vector is then processed through three independent fully connected layers and the LeakyReLU activation function is applied to obtain the raw attention score for each submission category. The original attention scores of the three submission categories are softmax normalized to obtain the weight coefficient of each submission category. The weight coefficient of each submission category is weighted and summed with the basic weight parameter of each submission category to obtain the user-item edge weight.

6. The method for dividing developer communities and recommending projects for open source software projects according to claim 1, characterized in that: The method samples 1st to 3rd order paths for each user data and item data respectively, and aggregates the 1st to 3rd order paths based on the user embedding vector, the item embedding vector, and the user-item edge weight to obtain the aggregated path user embedding vector and the aggregated path item embedding vector, including: For each user data or item data, a preset number of 1st to 3rd order paths are sampled, and an initial vector for each path is generated based on the user embedding vector, item embedding vector, and user-item edge weight; Use gated recurrent units to process the initial vector of each path to obtain the path feature vector; The average value of all user-item edge weights in each path is taken as the path weight. The corresponding path feature vector is weighted using the path weight. The weighted path feature vectors are concatenated in the order of 1st, 2nd, and 3rd order and then layer-normalized to obtain the final output aggregated path user embedding vector or aggregated path item embedding vector.

7. The method for dividing developer communities and recommending projects for open source software projects according to claim 6, characterized in that: The method of sampling a preset number of 1st to 3rd order paths for each user data or item data and generating an initial vector for each path based on the user embedding vector, the item embedding vector, and the user-item edge weight includes: Batch sampling is performed for the 1st to 3rd order paths of each user node u. The specific sampling method is as follows: (1) The first-order path sampling is the collaborative relationship of "user u→project p", and the user embedding vector h is concatenated. u , item embedding vector h p , the user-item edge weight of the interaction edge ω (u,p) , generate the first-order path initial vector x1=[h u ;h p ;ω (u,p) ]; (2) The second-order path sampling is the collaborative relationship of "user u→project p→user u′", and the user embedding vector h of user u is concatenated. u , user embedding vector h of user u′ u′ , the item embedding vector h of item p p , the user-item edge weight ω of the interaction edge between user u and item p (u,p) , the user-item edge weight ω of the interaction edge between user u′ and item p (u′,p) , generate the second-order path initial vector x2=[h u ;h p ;h u′ ;ω (u,p) ;ω (u′,p) ]; (3) The third-order path sampling is the associated transfer mode of "user u→item p→user u′→item p′", and the user embedding vector h of user u is concatenated. u , user embedding vector h of user u′ u′ , the item embedding vector h of item p p , the item embedding vector h of item p′ p′ , the user-item edge weight ω of the interaction edge between user u and item p (u,p) , the user-item edge weight ω of the interaction edge between user u′ and item p (u′,p) , the user-item edge weight ω of the interaction edge between user u′ and item p′ (u′,p′) , generate the initial vector x3 of the third-order path of user node u = [h u ;h p ;h u′ ;h p′ ;ω (u,p) ;ω (u′,p) ;ω (u′,p′) ]; Batch sampling is performed for the 1st to 3rd order paths of each project node p. The specific sampling method is as follows: (1) The first-order path sampling is the collaborative relationship of "project p→user u", and the user embedding vector h is concatenated. u , item embedding vector h p , the user-item edge weight of the interaction edge ω (u,p) , generate the initial vector y1 of the first-order path of the project node p = [h p ;h u ;ω (u,p) ]; (2) The second-order path sampling is the collaborative relationship of "project p → user u → project p'", and the user embedding vector h of user u is concatenated. u , the item embedding vector h of item p′ p′ , the item embedding vector h of item p p , the user-item edge weight ω of the interaction edge between user u and item p (u,p) , the user-item edge weight ω of the interaction edge between user u and item p′ (u,p′) , generate the initial vector y2 of the second-order path of the project node p = [h p ;h u ;h p′ ;ω (u,p) ;ω (u,p′) ]; (3) The third-order path sampling is the associated transfer mode of "item p→user u→item p′→user u′", and the user embedding vector h of user u is concatenated. u , user embedding vector h of user u′ u′ , the item embedding vector h of item p p , the item embedding vector h of item p′ p′ , the user-item edge weight ω of the interaction edge between user u and item p (u,p) , the user-item edge weight ω of the interaction edge between user u and item p′ (u,p′) , the user-item edge weight ω of the interaction edge between user u′ and item p′ (u′,p′) , generate the initial vector x of the third-order path of the project node p p =[h3;h u ;h p′ ;h u′ ;ω (u,p) ;ω (u,3′) ;ω (u′,p′) ].

8. The method for dividing developer communities and recommending projects for open source software projects according to claim 1, characterized in that: The developer community topology structure obtained by clustering based on the distance between two users includes: For user u i , if the neighborhood of ε contains i If the number of users whose distance does not exceed ε is not less than the minimum number of core points, then user u i is a core user; otherwise, user u i Not for core users; If user u j In the core user u i If user u is in the ε neighborhood of j For core users u i The density of users can be reached; Traverse all users and extract core users. For each core user, find all density-reachable users and form an initial community with the core user and the density-reachable users belonging to the same core user. Repeat the traversal of the communities. If two communities have common core users or density-reachable users, merge them into the same community. After the community is merged, users who do not belong to any community are treated as noise points and removed. Finally, output the community as a developer community to form a developer community.

9. The method for dividing developer communities and recommending projects for open source software projects according to claim 1, characterized in that: Outputting the project recommendation results according to the similarity includes: The similarity is normalized by the Softmax function to generate a probabilistic score and sort it. The projects that the user has participated in are filtered and the Top-N recommendation list is output based on the filtered sorting as the project recommendation result.

Images