Open source platform task matching method based on developer behavior graph and double-layer filtering

Abstract

The application discloses an open source platform task matching method based on a developer behavior graph and double-layer filtering, and the method comprises the following steps: S1, dividing the behavior characteristics of the developer into three dimensions to obtain a developer behavior characteristic data set; S2, identifying and screening out developers who do not meet the basic requirements; S3, constructing a lightweight knowledge graph G containing the nodes of the developers, the nodes of the tasks and the associated edges of the nodes by combining a relational database with a graph storage dev_task ; S4, obtaining the task requirement text Text req of the historical open source task and the open source task to be matched, obtaining a plurality of subtasks by decomposing the requirement of the open source task to be matched, and generating corresponding vectorized representations; S5, adopting a double-layer filtering strategy, constructing a primary matching layer to obtain a preliminary candidate developer set, and constructing a fine screening scoring layer to obtain a recommended result list.

Description

Technical Field

[0001] This invention relates to the fields of artificial intelligence, data mining, and open-source software development, and in particular to an open-source platform task matching method based on developer behavior graphs and two-layer filtering. Background Technology

[0002] In recent years, crowdsourced open-source platforms for scientific research have developed rapidly. Taking Redhill Open Source as an example, the platform has gathered over 120,000 developers, hosted more than 7,200 open-source projects, and released 595 maker tasks. On open-source platforms like Redhill, numerous developers are active. When new tasks (i.e., projects) are released, or existing projects have vulnerabilities, these developers are needed to complete or participate in maintenance. Traditionally, developers participate in tasks based on their personal willingness, and the platform does not intervene. While this eliminates management costs, it also allows developers with lower skill levels, inconsistent technical requirements, and lack of collaboration skills to infiltrate the platform, bringing uncertainty and unnecessary losses to project development and maintenance. Therefore, to improve the operational efficiency of open-source platforms and reduce the human and material costs required to complete various tasks on the platform, how to develop and automate methods to intelligently match the most suitable developers for a given task has become an urgent problem to be solved.

[0003] However, firstly, existing technologies have very little to do with the issue of automatically and intelligently matching developers with tasks on open-source platforms, to the point that there is a lack of relevant technical literature. Furthermore, even when expanding the problem to the broader topic of task allocation, existing methods still have many shortcomings that need to be addressed. The first is the issue of "availability." There is a two-way selection relationship between task requirements and allocation targets (i.e., developers in the context of this invention). From the perspective of open-source platforms, not only do allocation targets have the right to choose tasks, but it is also necessary to select allocation targets with sufficient skill, collaboration ability, and even a perfect delivery history based on task requirements. For example, existing technologies such as "Task Allocation Method and Task Allocation Device" (CN202410430777.5) often only focus on how to allocate tasks to the task queue, without paying sufficient attention to how to determine the coupling degree based on task requirements or developer behavioral characteristics, thereby ensuring that tasks are allocated to developers with sufficient skill and reliability. Secondly, even if the issue of "availability" is addressed, simply adding a tag for retrieval is far from sufficient; the issue of "quality" needs to be further resolved. The ability to accurately assess and fully utilize behavioral characteristics such as developer skills, historical task completion status, and collaborative relationships directly affects the accuracy of method recommendation results and user experience, thereby impacting the overall operational efficiency of the open-source platform. Summary of the Invention

[0004] To address the problems existing in the prior art, the purpose of this invention is to provide an open-source platform task matching method based on developer behavior graphs and two-layer filtering. Based on developer behavior graphs and two-layer filtering, the open-source platform can intelligently match developers according to task requirements and efficiently generate accurate recommendation results.

[0005] To achieve the above objectives, this invention provides an open-source platform task matching method based on developer behavior graphs and two-layer filtering, the method comprising the following steps:

[0006] S1. Divide the developer's behavioral characteristics into three dimensions: basic skills, collaborative relationships, and historical behavior. For all developers registered in the open source platform database, collect relevant data for each developer from these three dimensions to obtain a developer behavioral characteristic dataset.

[0007] S2. Traverse the developer behavior feature dataset to identify and filter out developers who are not genuine, have low-level skills, or are resistant to cooperation;

[0008] S3. Based on the developer behavior feature dataset filtered in step S2, a lightweight knowledge graph G containing developer nodes, task nodes, and their associated edges is constructed by combining a relational database with graph storage. dev_task ;

[0009] S4. Obtain the task requirement text for both historical open-source tasks and open-source tasks to be matched. req The open-source task to be matched is broken down into several sub-tasks, and corresponding vectorized representations are generated.

[0010] S5. A two-layer filtering strategy is adopted to construct a primary matching layer, import vectorized representations, and filter to obtain a preliminary candidate developer set G. init_candidate Based on this, a fine-tuning scoring layer is further constructed, which scores and ranks results from multiple dimensions, including collaboration ability score and collaboration reliability score, to finally obtain the recommended result list L. recom_result .

[0011] Furthermore, step S1 specifically includes the following steps:

[0012] S1.1 For the basic skills dimension, collect the developer's code commit history; traverse the developer's code commit history to obtain the programming languages ​​used by the developer and their frequency; input all the developer's historical code commits into the open source large language model, and obtain several personal technical tag keywords through the large language model;

[0013] S1.2. Regarding the collaboration dimension: Obtain a list of developers involved in all projects on the open-source platform, form a developer set, and build a developer collaboration network diagram based on this. , where the set of nodes The nodes in the set represent developers, and the edges represent the collection of edges. This represents the collaborative relationships between developers, with edge weights. Indicates the developer With developers The intensity of cooperation;

[0014] S1.3. The historical behavior dimension includes two indicators: task allocation response speed and code review pass rate; task allocation response speed This was obtained by calculating the average response time difference of developers' historical task assignments to open-source platforms; code review pass rate. Used to measure the quality and stability of code submitted by developers;

[0015] S1.4. Using the developer ID as the dictionary key, store the above three dimensions of behavioral features of each developer into the dictionary corresponding to that developer, and summarize to obtain the developer behavioral feature dataset, which contains several developers and their corresponding behavioral features.

[0016] Furthermore, in step S1.1, the open-source large language model can be Deepseek-R1 or Qwen3-8B.

[0017] Furthermore, in step S1.2, in the constructed developer collaboration network diagram Based on this, the Louvain community detection algorithm is used to identify core collaboration circles.

[0018] Furthermore, step S1.2 specifically includes the following steps:

[0019] S1.2.1 Logically treats each developer node as an independent community, with the initial number of communities equal to the number of nodes;

[0020] S1.2.2 For each node, calculate the modularity gain when moving it into the community of its neighbor node j. And execute a greedy strategy to move it to the module degree gain after the move. In the neighborhood community with the largest positive and absolute value, if there is no such neighborhood community, the node remains in its original community position; repeat this process for all nodes until no node can have a positive modularity gain. The movement;

[0021] S1.2.3. Treat each community obtained in step S1.2.2 as a new node, and the weight of the edge between two new nodes is the sum of the weights of all edges between the corresponding two communities. Reconstruct a new developer collaboration network graph. Repeat step S1.2.2, and repeat the process until the developer collaboration network diagrams are obtained from both previous and subsequent iterations. Until nothing changes;

[0022] S1.2.4. For each stable community ultimately obtained, each developer within a single community is considered a closely collaborating developer; thus, for each developer, a corresponding list L of closely collaborating developers can be obtained. close_collab .

[0023] Furthermore, in step S1.3, the task response speed is allocated. The following formula is used for calculation:

[0024]

[0025] in This is the actual timestamp of the task submission. Assign timestamps to tasks. Total number of open-source platform tasks participated in by the developer throughout history:

[0026] Furthermore, code review pass rate The calculation method is as follows:

[0027]

[0028] in The denominator is the number of historical code submissions that passed review. Total number of submissions The number of issue reports received for its historical code commits.

[0029] Furthermore, step S2 includes: traversing the developer behavior feature dataset D dev_behavior_feature For the basic skills dimension, if a developer's behavioral characteristics include any one or more of the following, then their corresponding data will be removed:

[0030] a) If the number of programming languages ​​used in the past exceeds the threshold, the developer is determined to be a non-genuine developer;

[0031] b) If the large language model summarizes fewer than 3 personal technical tag keywords, the developer is judged to be a low-level developer.

[0032] Regarding the collaboration relationship dimension, if a developer has fewer than the set number of closely collaborating developers, they are considered to be conflicting collaborators, and their corresponding data is removed.

[0033] For the behavioral characteristics dimension, if the developer's behavioral characteristics include any one or more of the following, then their corresponding data will be removed:

[0034] a) The developer's project allocation response speed If the threshold is exceeded, the developer is considered a low-level developer.

[0035] b) Code review pass rate If the skill level is below the set threshold, the developer is considered a low-level developer.

[0036] Furthermore, step S3 specifically includes the following steps:

[0037] S3.1. Predefine two types of node entities: Developer and Task, which correspond to developers and their behavioral characteristics, and historical tasks of the open source platform, respectively.

[0038] S3.2. Create the following corresponding data tables in the relational database, and then add the developer behavior feature dataset D, which has been filtered in step S2. dev_behavior_feature Enter the corresponding values ​​into the table;

[0039] S3.3. Select Neo4j as the graph database and initialize the graph structure. First, create node labels and primary key indexes for the two types of node entities Developer and Task respectively. Then, based on the relational database tables developers and tasks created in step S3.2, generate the corresponding nodes in batch import mode.

[0040] S3.4. Based on the association table dev_tasks created in step S3.2, establish the association relationship between the developer and the task node;

[0041] S3.5. Construct a lightweight knowledge graph G. dev_task When the historical task data of developers or open-source platforms changes, the new node is added to the graph database according to steps S3.1 to S3.4, and corresponding participation relationship edges and attribute values ​​are added to complete the lightweight knowledge graph G. dev_task The corresponding updates.

[0042] Furthermore, step S4 specifically includes the following steps:

[0043] S4.1. For a new input, open-source task to be intelligently matched, obtain its task requirement text (Text). req The list of clauses L is obtained using open-source natural language processing tools. sub_sen ;

[0044] S4.2. Iteration Clause List L sub_senFor each clause, extract the list of entities contained in each clause;

[0045] S4.3. Call the dependency parsing function provided by the Spacy library, select entities that exist in the entity list and whose dependency relationship is subject or object as the main entities of the clause, and finally obtain the clause entity list L corresponding to each clause. sub_sen_entities ;

[0046] S4.4. Traversing the Clause Entity List L sub_sen_entities Clauses with the same main entity are grouped together, resulting in several groups, each containing several clauses.

[0047] S4.5. Based on the open-source natural language processing library Spacy, each group is represented by a vector.

[0048] S4.6. Based on the group vector results obtained in step S4.5, perform hierarchical clustering on each group;

[0049] S4.7. Obtain the corresponding task requirement text. req It is described by several sets of clauses, each set corresponding to a task sub-requirement and having a corresponding set of vector representations.

[0050] Furthermore, step S5 specifically includes the following steps:

[0051] S5.1 Construct the primary matching layer, using the lightweight knowledge graph G obtained in step S3. dev_task Based on this, a set of candidate developers with basic skill relevance to the open-source tasks to be recommended can be quickly selected;

[0052] S5.2 constructs a fine-screening scoring layer to evaluate the initial candidate developer set G. init_candidate Further multi-dimensional scoring and ranking;

[0053] S5.3 weights and merges the collaboration capability score and the collaboration reliability score to form the final comprehensive score used for ranking. This is used to determine the priority of candidate developers in the recommendation list.

[0054] The beneficial effects of this invention are as follows:

[0055] In this invention, to efficiently and accurately generate intelligent matching results for open-source platform tasks, the invention first addresses the "availability" aspect, incorporating developer behavioral characteristics and other attributes into the task allocation considerations. This invention first divides developer behavioral characteristics into three dimensions: basic skills, collaborative relationships, and historical behavior, using this method for precise quantitative representation. Regarding the "quality" aspect, the invention first designs filtering rules to obtain truly valid data; second, it constructs a lightweight knowledge graph containing developer nodes, task nodes, and their associated edges using a combination of relational databases and graph storage, ensuring structured, efficient, and accurate data storage; third, it utilizes natural language processing technology to break down the given task requirement text into several sub-task requirements and quantifies them, ensuring that subsequent matching of each sub-task with developers possessing different strengths based on semantic similarity; finally, a two-layer filtering strategy is adopted. After obtaining a preliminary candidate developer set through the initial matching layer, a further refined screening and scoring layer is constructed, performing multi-dimensional scoring and ranking from two perspectives: collaborative ability score and collaborative reliability score, ultimately obtaining a recommended result list. This invention fills a gap in the field of intelligent task matching for open-source platforms and proposes a precise and effective automated method, thus effectively solving this problem. Attached Figure Description

[0056] Figure 1 This is a flowchart illustrating the open-source platform task matching method based on developer behavior graphs and two-layer filtering, as described in this invention.

[0057] Figure 2 This is a sub-graph of the behavioral feature data collection process in the open-source platform task matching method based on developer behavior graph and two-layer filtering in this invention;

[0058] Figure 3 This is a sub-graph of the data filtering process in the open-source platform task matching method based on developer behavior graphs and two-layer filtering in this invention;

[0059] Figure 4 This is a sub-graph of the knowledge graph construction process in the open-source platform task matching method based on developer behavior graph and two-layer filtering in this invention;

[0060] Figure 5 This is a flowchart of the task requirement decomposition and vectorization process in the open-source platform task matching method based on developer behavior graph and two-layer filtering in this invention.

[0061] Figure 6 This is a flowchart of the two-layer filtering process in the open-source platform task matching method based on developer behavior graph and two-layer filtering in this invention. Detailed Implementation

[0062] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0063] In the description of this invention, it should be noted that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing the invention and for simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on the invention. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0064] In the description of this invention, it should be noted that, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances.

[0065] The following combination Figures 1-6 Specific embodiments of the present invention will be described in detail below. It should be understood that the specific embodiments described herein are for illustrative and explanatory purposes only and are not intended to limit the present invention.

[0066] An intelligent task matching method for open-source platforms based on developer behavior graphs and two-layer filtering, such as Figure 1 As shown, the specific steps include:

[0067] S1. Developer behavioral characteristics are divided into three dimensions: basic skills, collaborative relationships, and historical behavior. For all developers registered in the open-source platform database, relevant data for each developer is collected from each of these three dimensions to obtain the developer behavioral characteristic dataset D. dev_behavior_feature ;

[0068] S2. Traverse the developer behavior feature dataset D dev_behavior_feature Identify and filter out developers who are not genuine, have low-level, or are resistant to cooperation;

[0069] S3. The developer behavior feature dataset D after filtering in step S2 dev_behavior_featureBuilding upon this foundation, a lightweight knowledge graph G is constructed by combining relational databases with graph storage. This graph includes developer nodes, task nodes, and their associated edges. dev_task ;

[0070] S4. Obtain the task requirement text for both historical open-source tasks and new input / open-source tasks awaiting intelligent matching. req Regardless of the type or description of the open-source task, there will always be a task requirement text expressed in natural language. All tasks are broken down into several sub-tasks, and corresponding vectorized representations are generated to facilitate matching each sub-task with developers with different strengths based on semantic similarity.

[0071] S5. Employ a two-layer filtering strategy to construct a primary matching layer and filter to obtain a preliminary candidate developer set G. init_candidate Based on this, a fine-tuning scoring layer is further constructed, which scores and ranks results from multiple dimensions, including collaboration ability score and collaboration reliability score, to finally obtain the recommended result list L. recom_result .

[0072] Furthermore, such as Figure 2 As shown, step S1 specifically includes the following steps:

[0073] S1.1 focuses on the developer's basic skills by collecting their code commit history. It iterates through the commit history, using regular expressions to identify the corresponding programming language for each commit and then summarizing the historical usage frequency of each language. All historical code commits are input into an open-source large language model (e.g., Deepseek-R1, Qwen3-8B), prompting the following: "Analyze the technical characteristics used in historical code commits, including commonly used development frameworks (e.g., React, Vue, Django), and related technical fields (e.g., artificial intelligence, big data, blockchain, cloud computing), and generate a maximum of three unique, highly condensed corresponding technical keywords. Each keyword must be annotated with the corresponding code file and start and end line numbers as technical evidence. If the technical characteristics are insufficient to generate three keywords, fewer than three valid keywords are allowed." The large language model then summarizes a maximum of three keywords as the developer's personal technical tags. This yields the programming languages ​​used by the developer and their frequencies, as well as several personal technical tag keywords.

[0074] S1.2. Regarding the collaboration relationship dimension, the goal is to determine the list L of closely collaborating developers for each developer. close_collab Obtain a list of developers involved in all projects on the open-source platform, forming a developer pool, and then build a developer collaboration network diagram based on this pool. , where the set of nodes The nodes in the set represent developers, and the edges represent the collection of edges. This represents the collaborative relationships between developers, with edge weights. Indicates the developer With developers The cooperation strength is calculated as shown in formula (1.1), where This refers to the number of times both were submitted together. Total number of submissions to the platform:

[0075] .

[0076] Furthermore, in the constructed developer collaboration network diagram Based on this, the Louvain community detection algorithm is used to identify the core cooperation circle. The steps are as follows:

[0077] S1.2.1 Logically treats each developer node as an independent community, meaning the initial number of communities equals the number of nodes (developers).

[0078] S1.2.2 For each node, calculate the modularity gain when moving it into the community of its neighbor node j. And execute a greedy strategy to move it to the module degree gain after the move. In the neighborhood community with the largest positive and absolute value, the node remains in its original community position if no such neighborhood community exists. Repeat this process for all nodes until no node has a positive modularity gain. The movement. The value is calculated as shown in formula (1.2), where For the sum of edge weights within the community, The total edge weight of the community association. For nodes The sum of the edge weights, Let i be the connection weight between node i and the target community. A diagram of the current developer collaboration network. The sum of the weights of all edges in the middle:

[0079]

[0080] S1.2.3. Treat each community obtained in step S1.2.2 as a new node, and the weight of the edge between two new nodes is the sum of the weights of all edges between the corresponding two communities. Reconstruct a new developer collaboration network graph. Repeat step S1.2.2, looping the process until the developer collaboration network diagrams are obtained from both previous and subsequent iterations. Until nothing changes.

[0081] S1.2.4. For each stable community ultimately obtained, each developer within that community is considered a closely collaborating developer. Therefore, for each developer, a corresponding list L of closely collaborating developers can be obtained. close_collab .

[0082] S1.3. The historical behavior dimension includes two metrics: task allocation response speed and code review pass rate. Task allocation response speed... This is obtained by calculating the average response time difference of developers historically assigning tasks to the open-source platform, as shown in formula (1.3), where This is the actual timestamp of the task submission. Assign timestamps to tasks. This represents the total number of tasks a developer has historically participated in on the open-source platform. Index number of the tasks the developer participated in ( ):

[0083]

[0084] Code review pass rate Used to measure the stability of code quality submitted by developers, the calculation method is shown in formula (1.4):

[0085]

[0086] in The denominator is the number of historical code submissions that passed review. Total number of submissions The number of issue reports received for its historical code commits.

[0087] S1.4. Using the developer ID as the dictionary key, store the above three dimensions of behavioral features for each developer into the corresponding dictionary, and summarize them to obtain the developer behavioral feature dataset D. dev_behavior_feature This dataset contains several developers and their corresponding behavioral characteristics.

[0088] like Figure 2 As shown in this embodiment, several data points from developers on an open-source platform are collected and aggregated to obtain a developer behavior feature dataset D. dev_behavior_feature As shown in Table 1 below:

[0089] Table 1: Developer Behavioral Characteristics Dataset D dev_behavior_feature (Partial) illustration

[0090]

[0091] Furthermore, step S2 specifically includes the following steps:

[0092] S2.1. Traverse the developer behavior feature dataset D dev_behavior_feature For the basic skills dimension, if a developer's behavioral characteristics include any one or more of the following, then their corresponding data will be removed:

[0093] a) If the number of programming languages ​​used in the past exceeds the threshold (the threshold can be defined as needed, such as 15), the developer is determined to be a non-genuine developer.

[0094] b) If the large language model summarizes fewer than 3 personal technical tag keywords, the developer is judged to be a low-level developer.

[0095] S2.2. Regarding the collaboration relationship dimension, if a developer has fewer than a certain number of closely collaborating developers (this threshold can be defined as needed, such as 3), then the developer is considered to be a conflicting collaborator, and their corresponding data is removed.

[0096] S2.3. Regarding the behavioral characteristic dimension, if the developer's behavioral characteristic includes any one or more of the following situations, then the corresponding data shall be removed:

[0097] a) The developer's project allocation response speed If the time frame is too long (the threshold for judgment can be defined as needed, such as 7 days), the developer is judged to be a low-level developer.

[0098] b) Code review pass rate If the threshold is too low (the threshold can be defined as needed, such as 50%), the developer is considered a low-level developer.

[0099] like Figure 3 As shown, in this embodiment, the following IDs are determined to be: Dev009 (more than 15 programming languages ​​used historically); Dev004 (fewer than 3 personal technical tag keywords); and Dev012 (project response speed). Developers with fewer than 5 close collaborating developers were deemed low-level developers; Dev006 (with fewer than 5 close collaborating developers) were deemed resistant to collaboration and were filtered out of the dataset. The filtered developer behavior feature dataset D dev_behavior_feature As shown in Table 2 below:

[0100] Table 2: Filtered Developer Behavior Feature Dataset D dev_behavior_feature Indication

[0101]

[0102] Furthermore, step S3 specifically includes the following steps:

[0103] S3.1. Predefine two types of node entities: Developer and Task, which correspond to developers and their behavioral characteristics, and historical tasks of the open source platform, respectively;

[0104] S3.2. Create the following corresponding data tables in the relational database, and then add the developer behavior feature dataset D, which has been filtered in step S2. dev_behavior_feature The corresponding values ​​should be entered into the table, including:

[0105] a) The developers table stores developer IDs, programming languages ​​used and frequency, personal technical tag keywords, a list of closely collaborating developers, task assignment response speed, and code review pass rate;

[0106] b) The tasks table is used to store task IDs, task requirement descriptions, technical tags, scale, and timeframe;

[0107] c) The associated table dev_tasks is used to record the correspondence between developers and historical tasks of the open source platform, including whether a developer participated in a historical task of a certain open source platform, and the task allocation response speed and code review pass rate in the tasks they participated in.

[0108] S3.3. Select Neo4j as the graph database and initialize the graph structure. First, create node labels and primary key indexes for the two types of node entities Developer and Task respectively. Then, based on the relational database tables developers and tasks created in step S3.2, generate the corresponding nodes in batch import mode.

[0109] S3.4. Further, after generating nodes in step S3.3, based on the association table dev_tasks created in step S3.2, an association relationship between the developer and the task nodes is established, specifically including:

[0110] a) Based on the developer code submission history collected in step S1, establish participation relationship edges between each Developer and Task node. If a participation relationship edge exists between a Developer node and a Task node, it indicates that the developer has participated in historical tasks of this open-source platform;

[0111] (b) In graph databases, edges not only represent a relationship between two nodes, but are themselves equivalent to database records, carrying fields (i.e., attributes). These fields include numbers, strings, and timestamps. Utilizing this characteristic, all participation relationship edges are traversed. For a single participation relationship edge, if the personal technical tag keyword attribute value of the Developer node it connects to overlaps with the technical tag attribute value of the Task node, then the participation relationship edge is further labeled as "technical matching participation," used to assist in the subsequent generation of recommendation judgment results.

[0112] c) Further, traverse all participating relationship edges and add attributes to record the specific behavioral characteristics of the developer corresponding to the Developer node in the historical tasks of the open source platform corresponding to the Task node. The added attributes include task allocation response speed and code review pass rate, which are used to assist in the subsequent generation of recommendation judgment results.

[0113] S3.5. After the above steps, a lightweight knowledge graph G is constructed. dev_task Based on this, when the historical task data of developers or open-source platforms increases or decreases, the new nodes are added to the graph database according to the process of steps S3.1 to S3.4, and corresponding participation relationship edges and attribute values ​​are added to complete the lightweight knowledge graph G. dev_task The corresponding updates.

[0114] like Figure 4 As shown, in this embodiment, a lightweight knowledge graph G is constructed based on the above sample data. dev_task The relevant characteristics are shown in Table 3 below:

[0115] Table 3: The constructed lightweight knowledge graph G dev_task Related features

[0116]

[0117] Furthermore, step S4 specifically includes the following steps:

[0118] S4.1. For a new input, open-source task to be intelligently matched, obtain its task requirement text (Text). req The text describes a process using existing open-source natural language processing tools to divide a language into several semantically complete and relatively independent clauses, resulting in a clause list L. sub_sen Open-source natural language processing tools can include Spacy and NLTK.

[0119] S4.2. Iteration Clause List L sub_senFor each clause, entity recognition analysis is performed based on the deep learning pre-trained Named Entity Recognition (NER) model en_core_web_lg provided by the Python third-party library Spacy. The analysis results are in the form of [{'Entities':entities,'Labels':labels,'Position_Start':position_start, 'Position_End':position_end}]. From this, the list of entities contained in each clause is extracted.

[0120] S4.3. In this case, a clause may correspond to multiple entities. Further, to identify the most representative core entity in each clause, the dependency parsing function provided by the Spacy library is invoked to select the entity that exists in the entity list and whose dependency relation is subject (nsubj) or object (dobj) as the primary entity of that clause. Finally, the clause entity list L corresponding to each clause is obtained. sub_sen_entities ;

[0121] S4.4. Traversing the Clause Entity List L sub_sen_entities Clauses with the same main entity are grouped together, resulting in several groups, each containing several clauses.

[0122] S4.5. Based on the existing open-source natural language processing library Spacy, each group is vectorized. Specifically, for a single group, each clause is first segmented, then pause word filtering is performed on the segmentation results, and the word vectors corresponding to the retained words are retrieved from the Spacy library. The sentence vector corresponding to each clause is the average of the word vectors of all retained words contained in that clause, calculated as shown in formula (4.1). The sentence vector representing a single clause. This indicates the number of retained words (i.e., the effective word segments after removing stop words) in the clause. Indicates the first The word vectors of the retained words in the pre-trained model provided by the third-party library:

[0123]

[0124] Obtain the sentence vector corresponding to each clause in this group. Then, the average of the sums is taken to obtain the group vector corresponding to the group, as shown in formula (4.2), where, This represents the overall vector representation of the group of subtasks. This indicates the number of clauses contained in the group. Indicates the first The sentence vector corresponding to each clause, calculated using formula (4.1):

[0125]

[0126] Finally, the vectorized representation of each group can be obtained;

[0127] S4.6. Based on the group vector results obtained in step S4.5, perform hierarchical clustering on each group, as follows: arbitrarily select a group and calculate the cosine similarity between this group and the group vectors of other groups, setting a threshold. (The value range is [0, 1], and can be set according to actual needs, such as 0.5). This group is compared with all other groups whose vectors have a cosine similarity greater than a threshold. The groups are merged, and the aforementioned operation is repeated until no group has a cosine similarity of group vectors greater than the threshold with any of the other groups. So far, the cosine similarity calculation is shown in formula (4.3), where, Indicates the first The group vector and the first Cosine similarity between groups of vectors and The first Group and No. Vector representation of a group Indicates the first The Euclidean norm of a set of vectors:

[0128]

[0129] S4.7. At this point, the corresponding task requirement text (Text) is obtained. req It is described by several sets of clauses, each set corresponding to a task sub-requirement and having a corresponding set of vector representations.

[0130] like Figure 5 As shown, in this embodiment, taking a new input, an open-source task to be intelligently matched as an example, for a task requirement text (Text) req "Develop a distributed machine learning framework based on Python, supporting TensorFlow integration and cross-platform deployment, requiring highly scalable code and real-time data processing capabilities." First, it is divided into clauses to obtain a clause list L. sub_sen As shown in Table 4:

[0131] Table 4: Clause List L sub_sen Indication

[0132]

[0133] Then, entities are extracted from the clauses and grouped according to the entities to obtain the clause entity list L for each clause. sub_sen_entities The grouping results are shown in Table 5 below:

[0134] Table 5: List of Clause Entities for Each Clause L sub_sen_entities And the grouping results illustration

[0135]

[0136] The corresponding grouping results are: Group 1 - Framework Development (Sen1); Group 2 - Framework Integration (Sen2); Group 3 - Deployment Optimization (Sen3); Group 4 - Code Quality (Sen4, Sen5).

[0137] Further, following step S4.5, after segmenting and filtering stop words for each clause in each group, the word vectors corresponding to the retained words are retrieved from the Spacy database. The average word vectors are accumulated to obtain the sentence vectors corresponding to each clause. Within each group, the sentence vectors of the clauses are accumulated and averaged to obtain the group vector. For example, taking the clause with the clause ID "Sen3" as an example, the list of retained words and their corresponding word vectors after segmentation and removal of stop words are shown in Table 6. All of these vectors are numerical representations. Finally, the sentence vector corresponding to this clause is [0.10175,−0.01375,0.059,0.1705,0.118,…]. Since this group contains only one clause, the group vector is [0.10175,−0.01375,0.059,0.1705,0.118,…].

[0138] Table 6: Schematic diagram of the final descriptions of several sets of clauses and their corresponding vector representations

[0139]

[0140] Then, as described in step S4.6, set the cosine similarity threshold. With a value of 0.5, hierarchical clustering is performed on the vectorized groups to obtain the final several groups of clause descriptions and corresponding vector representations, as shown in Table 7 below:

[0141] Table 7: Schematic diagram of the final descriptions of several sets of clauses and their corresponding vector representations

[0142]

[0143] Furthermore, step S5 specifically includes the following steps:

[0144] S5.1 Construct the primary matching layer, using the lightweight knowledge graph G obtained in step S3. dev_taskBased on this, a set of candidate developers with basic skill relevance to the open-source task to be recommended is quickly selected. An improved collaborative filtering algorithm is used, which calculates the corresponding task requirement text obtained in step S4. req The Jaccard similarity between the vectors of each sub-requirement group and the set of word vectors corresponding to each developer's personal technical tag keywords (also obtained using the Spacy library) is used to obtain the skill matching score of each developer and sort them from high to low. One developer was included in the initial candidate set. (The value is a positive integer greater than 0; the specific value can be determined according to actual needs). Simultaneously, calculate the vectors of all historical task sub-requirement groups and the newly input task requirement text to be matched. req The Jaccard similarity between the vectors of each sub-requirement group is used to select the historical task with the highest similarity, obtain the list of developers involved in the historical task with the highest similarity, and include them all in the preliminary candidate set. This yields a preliminary candidate developer set G containing several developers. init_candidate ;

[0145] S5.2 constructs a fine-screening scoring layer to evaluate the initial candidate developer set G. init_candidate Further multi-dimensional scoring and ranking are conducted, specifically including the following two dimensions:

[0146] a) Collaboration Ability Score: For each candidate developer, their collaboration ability score is... Equal to the number of its closely collaborating developers (i.e., list L) close_collab length);

[0147] b) Collaboration Reliability Score: This score measures the quality of cooperation among candidate developers during historical task collaborations, combined with the corresponding task response speed calculated in step S1. With code review pass rate These two behavioral features are weighted and fused. The specific calculation is shown in formula (5.1), where, This represents a collaboration reliability score; a higher score indicates more reliable collaboration capabilities. It also corresponds to the response speed of assigned tasks. Derived from formula (1.3); This is the maximum tolerable response time (e.g., 7 days) for new projects, set as needed, and is used for normalization; code review pass rate. Derived from formula (1.4); These are weighting factors used to adjust the relative impact of response speed and review approval rate on the score:

[0148]

[0149] S5.3 weights and merges the collaboration capability score and the collaboration reliability score to form the final comprehensive score used for ranking. This is used to determine the priority of candidate developers in the recommendation list. The specific calculation is shown in formula (5.2), where, and As described in step S5.2; This is a weighting factor, distributed in the range [0, 1]. Its value can be defined as needed (e.g., 0.5), and is used to adjust the degree of influence of both factors on the final score.

[0150]

[0151] The above calculation method can obtain a more accurate comprehensive score, which fully reflects the matching degree of the candidates.

[0152] Traverse the initial candidate developer set G init_candidate All preliminary candidates were ranked as follows: The scores are sorted from highest to lowest to obtain the final recommended result list L. recom_result For example, in this embodiment, “Dev001 (overall score 4.48), Dev005 (overall score 4.12)”.

[0153] Expansion Plan

[0154] Introducing more behavioral data dimensions: In addition to current task response speed and code review pass rate, we can also collect data such as developers' activity level in project discussion forums and their ability to solve technical problems (by statistically analyzing the quality and quantity of their answers in the community). This data can more comprehensively reflect developers' technical capabilities and teamwork spirit, further improving the accuracy of matching.

[0155] Integrating external data: This involves integrating developer data from external technical communities, such as developers' contributions to other open-source projects. By introducing external data, the system's behavioral characteristics can be enriched, improving the accuracy of developer capability assessments.

[0156] Alternative solutions

[0157] (1) At the matching algorithm level: In the primary matching layer, in addition to improved collaborative filtering algorithms, deep learning-based methods, such as convolutional neural networks (CNNs) or recurrent neural networks (RNNs), can be used to extract features and match textual information (task descriptions, project experience, etc.) of tasks and developers. In the fine screening layer, for calculating collaboration tightness, a variant of the PageRank algorithm can be used to measure collaboration tightness based on the developer's influence in the social network, rather than solely relying on the number of projects jointly participated in.

[0158] (2) In terms of data storage: In addition to combining relational databases with graph storage, dedicated graph databases such as Neo4j can also be considered. Neo4j offers better optimization for graph data storage and query operations, thereby improving the processing efficiency of knowledge graphs. In some scenarios, if the data volume is small and real-time requirements are not high, document-oriented databases such as MongoDB can be used to store graph data in document form, simplifying the data storage structure.

[0159] Compared with the prior art, the present invention has the following advantages and effects:

[0160] First, this invention fills a gap in the relevant problem domain (i.e., the field of intelligent task matching on open-source platforms). Second, by accurately classifying developer behavioral characteristics into three dimensions—basic skills, collaborative relationships, and historical behavior—and quantitatively modeling them, it solves the problem of coarse matching caused by traditional methods relying on single tags or simple retrieval. Furthermore, it combines relational databases and graph storage technology to construct a lightweight knowledge graph, ensuring efficient storage and dynamic updates of the relationship between developers and tasks, overcoming the limitation of existing technologies that only focus on task queue allocation while ignoring the coupling degree of the allocation objects. Addressing the complexity of task requirements, this invention innovatively introduces natural language processing technology to semantically decompose and vectorize the task requirement text. Through semantic similarity calculation, it achieves deep adaptation between subtasks and developer expertise, thereby solving the matching bias problem caused by traditional methods ignoring task semantic features. Building upon this foundation, a two-layer filtering strategy is employed: a primary matching layer quickly filters candidates who meet basic skill requirements, while a secondary screening and scoring layer uses a multi-dimensional weighted fusion of collaboration ability scores (number of closely collaborating developers) and collaboration reliability scores (response speed, code review pass rate). This approach not only overcomes the initial screening challenge of "availability" but also optimizes the refined evaluation of "quality" through a dynamic scoring mechanism, significantly reducing the risk of inefficient collaboration. Furthermore, the developer collaboration network built upon the Louvain community discovery algorithm not only identifies core collaboration circles to support team task recommendations but also leverages historical behavioral data accumulation and incremental update mechanisms to accommodate cold-start scenarios for new developers, resolving the recommendation failure problem caused by data sparsity in traditional methods. Finally, the fully automated processing and flexibly adjustable threshold parameter design enable this invention to reduce labor costs while adapting to the personalized needs of different open-source platforms, providing an efficient, accurate, and scalable general solution for large-scale, multi-scenario task matching.

[0161] Any process or method described in the flowcharts of this invention or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process, which can be implemented in any computer-readable medium for use by an instruction execution system, apparatus, or device. The computer-readable medium can be any medium containing a program for storage, communication, propagation, or transmission for use by the execution system, apparatus, or device, including read-only memory, magnetic disks, or optical disks.

[0162] In the description of this specification, references to terms such as "embodiment," "example," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, those skilled in the art can combine or combine the different embodiments or examples described in this specification and the features therein without causing contradiction.

[0163] While embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions, and alterations to the above embodiments within the scope of the present invention.

Claims

1. An open-source platform task matching method based on developer behavior graphs and two-layer filtering, characterized in that, The method includes: S1. Divide the developer's behavioral characteristics into three dimensions: basic skills, collaborative relationships, and historical behavior. For all developers registered in the open source platform database, collect relevant data for each developer from these three dimensions to obtain a developer behavioral characteristic dataset. The historical behavior dimension includes two indicators: task assignment response speed and code review pass rate. Calculate code review pass rate The formula is: ； The number of times historical code submissions have passed review. Total number of submissions The number of issue reports obtained for historical code commits; S2. Traverse the developer behavior feature dataset to identify and filter out developers who do not meet the requirements; S3. On the developer behavior feature dataset filtered in step S2, a lightweight knowledge graph containing developer nodes, task nodes and their associated edges is constructed by combining a relational database with graph storage. S4. For both historical open-source tasks and open-source tasks to be matched, obtain their task requirement text, divide them into several clauses, group the clauses with the same main entity into the same group, and generate the corresponding vectorized representation. For a single group, each clause is first segmented and pause words are filtered out. The word vectors corresponding to the retained words are then retrieved, and the sentence vectors for each clause are also retrieved. The average of the word vectors of all retained words contained in the clause is calculated using the following formula: ； To retain the number of words in this clause, For the first The word vectors of each retained word in the pre-trained model provided by a third-party library are obtained; Then, the average of the sums is taken to obtain the corresponding group vector. : ； The number of clauses contained in this group. For the first The sentence vector of each clause; After obtaining the group vectors, perform hierarchical clustering on each group: arbitrarily select a group and calculate the cosine similarity between that group and the group vectors of other groups: ； The cosine similarity between this group and all its group vectors is greater than a threshold. The groups are merged until no group has a cosine similarity to the group vectors of the remaining groups that is greater than a threshold. So far, we have obtained group vector representations of several corresponding task sub-requirements; S5. A two-layer filtering strategy is adopted, including: S5.1 constructs a primary matching layer, filtering out a set of candidate developers with basic skill relevance to the open-source tasks to be recommended based on a lightweight knowledge graph: An improved collaborative filtering algorithm is employed. By calculating the Jaccard similarity between the vectors of each sub-requirement group in the corresponding task requirement text and the word vector set corresponding to each developer's personal technical tag keywords, the skill matching score of each developer is obtained and sorted from high to low. Several developers were included in the initial candidate set; It is a positive integer greater than 0; At the same time, calculate the Jaccard similarity between the vectors of all historical task sub-requirement groups and the vectors of each sub-requirement group of the new input task requirement text to be matched, select the historical task with the highest similarity, obtain the list of developers participating in the historical task with the highest similarity and include them all in the preliminary candidate set. This yields an initial set of candidate developers, comprising several individuals. S5.2 constructs a fine-screening scoring layer to score and rank the initial candidate developer set along two dimensions: a) Collaboration Ability Score: For each candidate developer, their collaboration ability score is... Equal to the number of its closely collaborating developers; b) Collaboration reliability score: Response speed to task assignment With code review pass rate The weighted fusion formula is as follows: ； To score the reliability of collaboration, The maximum tolerable response time for the new project. As a weighting factor; S5.3 weights and integrates the collaboration capability score and the collaboration reliability score to form a comprehensive score. The formula is: ； The weighting factor is distributed in the range [0, 1]. The initial candidate developer set is traversed, and all initial candidates are sorted according to their comprehensive scores to obtain the recommendation result list.

2. The open-source platform task matching method based on developer behavior graphs and two-layer filtering as described in claim 1, characterized in that, Step S1 specifically includes the following steps: S1.1 For the basic skills dimension, collect the developer's code commit history; traverse the developer's code commit history to obtain the programming languages ​​used by the developer and their frequency; input all the developer's historical code commits into the open source large language model, and obtain several personal technical tag keywords through the large language model; S1.

2. Regarding the collaboration dimension: Obtain a list of developers involved in all projects on the open-source platform, form a developer set, and build a developer collaboration network diagram based on this. , where the set of nodes The nodes in the set represent developers, and the edges represent the collection of edges. This indicates the collaborative relationship between the developers; S1.

3. Calculate the relevant indicators for the historical behavior dimension; S1.

4. Using the developer ID as the dictionary key, store the three dimensions of behavioral features of each developer into the corresponding dictionary for that developer, and summarize to obtain the developer behavioral feature dataset, which contains several developers and their corresponding behavioral features.

3. The open-source platform task matching method based on developer behavior graphs and two-layer filtering as described in claim 2, characterized in that, In step S1.1, the open-source large language model adopts Deepseek-R1.

4. The open-source platform task matching method based on developer behavior graphs and two-layer filtering as described in claim 2, characterized in that, In step S1.1, the open-source large language model adopts Qwen3-8B.

5. The open-source platform task matching method based on developer behavior graph and two-layer filtering according to claim 2, characterized in that, In step S1.2, in the constructed developer collaboration network diagram Based on this, the Louvain community detection algorithm is used to identify core collaboration circles.

6. The open-source platform task matching method based on developer behavior graph and two-layer filtering according to claim 2, characterized in that, Step S2 involves filtering out developers who do not meet the requirements, including: traversing the developer behavior feature dataset; for the basic skills dimension, if a developer's behavior feature includes any one or more of the following conditions, then removing the corresponding data: a) If the number of programming languages ​​used in the past exceeds the threshold, the developer is determined to be a non-genuine developer; b) If the large language model summarizes fewer than 3 personal technical tag keywords, the developer is judged to be a low-level developer.

7. The open-source platform task matching method based on developer behavior graph and two-layer filtering according to claim 6, characterized in that, Regarding the collaboration relationship dimension, if a developer has fewer than the set number of closely collaborating developers, they are considered to be conflicting collaborators, and their corresponding data will be removed.

8. The open-source platform task matching method based on developer behavior graph and two-layer filtering according to claim 7, characterized in that, For the behavioral characteristics dimension, if the developer's behavioral characteristics include any one or more of the following, then their corresponding data will be removed: a) The developer's project allocation response speed If the threshold is exceeded, the developer is considered a low-level developer. b) Code review pass rate If the skill level is below the set threshold, the developer is considered a low-level developer.

9. The open-source platform task matching method based on developer behavior graphs and two-layer filtering according to claim 1, characterized in that, Step S4 specifically includes the following steps: S4.

1. For a new input open-source task to be intelligently matched, obtain its task requirement text and use open-source natural language processing tools to obtain a list of clauses; S4.

2. Traverse the list of clauses, and for each clause, extract the list of entities contained in each clause; S4.

3. Call the dependency parsing function provided by the Spacy library, select the entity that exists in the entity list and whose dependency relationship is subject or object as the main entity of the clause, and finally obtain the clause entity list corresponding to each clause; S4.

4. Traverse the list of clause entities, group clauses with the same main entity into the same group, and finally obtain several groups, each containing several clauses; S4.

5. Based on the open-source natural language processing library Spacy, each group is represented by a vector. S4.

6. Based on the group vector results obtained in step S4.5, perform hierarchical clustering on each group; S4.

7. Obtain several sets of clause descriptions corresponding to the given task requirement text. Each set corresponds to a task sub-requirement and has a corresponding group vector representation.

Images