JP2022178776A - Applicability/non-applicability determination method and program - Google Patents

Abstract

To apply a highly reliable correction file to a development program.SOLUTION: The presence or absence of communications between a person in charge of development and experts/reviewers, which is detected by analysis of conversation data, and a merge determination result (application determination result) are presented to a person responsible for development. A screen g11 shows a graph where participants are indicated by nodes and nodes of the person in charge of development and participants who have had conversations with the person in charge of development are connected by branches. A screen g12 shows a conversation presence/absence table T0 and a merge determination result M0. The conversation presence/absence table T0 has items of usename, role, and conversation presence/absence. The merge determination result M0 indicates merge OK/NG. Since the conversation presence/absence table T0 shows that sato.hanako (person in charge of development) who has performed file correction has had conversations with yamada.taro (expert), yoshida.jiro (expert), and saito.goro (reviewer), the merge determination result for a correction file to a development program is displayed as merge OK.SELECTED DRAWING: Figure 17

Description

The present invention relates to an applicability determination method and program.

In software development, development proceeds while repeatedly applying files such as source code whose functions have been modified to the development program.
As a related technique, for example, a technique has been proposed for determining whether or not a valid indication has been commented based on a record file indicating an indicationr who made a comment in a review. A technology has also been proposed that evaluates the skill level and the number of reviewers who have participated in a review, and transmits the evaluation results by e-mail.

JP 2019-133558 A JP 2013-033391 A

However, the above background art does not necessarily mean that the commenter is familiar with the modified program. If a person unfamiliar with the modified program makes a valid point, or if a person with a high skill level but not familiar with the modified program makes a point, the correct It is conceivable that such comments could not be made.

In one aspect, the present invention enables application of highly reliable modified files to the program by determining whether the person who modified the modified program has communicated with a person familiar with the modified program. It is an object of the present invention to provide an applicability determination method and a program.

In order to solve the above problems, an applicability determination method is provided. The applicability determination method is that when a program is modified, the computer identifies an expert who has experience modifying the program based on the modification history information of the program, and based on the conversation information recorded in the communication service system. Then, the presence or absence of communication between the person in charge of development who modified the program and the expert is determined, and the applicability of the modified program is determined based on the result of the determination.

Further, in order to solve the above problems, there is provided a program that causes a computer to execute the same process as the applicability determination method.

According to one aspect, application of highly reliable modification files to development programs is enabled.

1 is a diagram for explaining an example of an information processing device according to a first embodiment; FIG. It is a figure which shows an example of the functional block of the information processing apparatus of 2nd Embodiment. It is a figure which shows an example of the hardware constitutions of an information processing apparatus. FIG. 4 is a diagram for explaining an example of GitHub operation; It is a figure which shows an example of collection operation|movement of conversation information. It is a figure which shows an example of extraction operation|movement of conversation data. It is a figure which shows an example of a chat application table. FIG. 10 is a diagram showing an example of a pull request conversation table; FIG. FIG. 10 is a diagram illustrating an example of data extraction from commit information of a master branch; FIG. 10 is a diagram illustrating an example of data extraction from commit information of a development branch; FIG. 10 is a diagram showing an example of a master branch update table; FIG. FIG. 10 is a diagram showing an example of a development branch update table; FIG. FIG. 4 is a diagram showing an example of data extraction from pull request information; It is a figure which shows an example of a pull request concerned party table. It is a figure which shows an example of a chat application table. FIG. 10 is a diagram showing an example of a pull request conversation table; FIG. It is a figure which shows an example of the presentation screen of a conversation presence/absence. 4 is a flow chart showing an example of the operation of the information processing device;

Hereinafter, this embodiment will be described with reference to the drawings.
[First embodiment]
FIG. 1 is a diagram for explaining an example of an information processing apparatus according to a first embodiment. The information processing device 1 includes a control unit 1a and a storage unit 1b. The control unit 1a is implemented by, for example, a processor (not shown) included in the information processing apparatus 1 executing a predetermined program. The storage unit 1b is used as a main storage device of the information processing apparatus 1, and stores, for example, software development history information, conversation information, and the like.

When the program is modified, the control unit 1a identifies an expert who has experience of modifying the program based on the modification history information of the program. Based on the conversation information recorded in the communication service system, the control unit 1a determines whether there is communication between the person in charge of development who modified the program and the expert, and based on the result of the determination, applicability of the modified program.

The flow of operation will be described using the example in FIG. In the following description, it is assumed that the modification of the program is modification of the file.
[Step S1] In software development, a file is modified (addition of a new function, bug correction, etc.) as a modification of a program by a person in charge of development. Note that the person in charge of development is, for example, the person who made corrections such as adding functions to the file.

[Step S2] Based on the software development revision history information 2a, the control unit 1a identifies an expert in file revision. The revision history information 2a is, for example, information in which the development history is managed for each version released from the software development platform. Note that the expert corresponds to the predecessor who developed or modified the modified file in the past.

[Step S3] The control unit 1a extracts conversation information during the period in which the file was modified from the communication service system 2b. The communication service system 2b can use, for example, GitHub (registered trademark) or Mattermost (registered trademark).

[Step S4] Based on the conversation information, the control section 1a detects whether or not there is communication between the person in charge of development who modified the file and the expert. If it is detected that there is communication between the person in charge of development and the expert, the process proceeds to step S5, and if it is detected that there is no communication, the process proceeds to step S6.

[Step S5] The control unit 1a determines that the correction file containing the corrected portion can be applied to the program under software development.
[Step S6] The control unit 1a determines that it is not possible to apply the correction file containing the corrected portion to the program under software development.

In this manner, the information processing apparatus 1 detects whether or not communication is established between the person in charge of development who has corrected the file and the expert, based on the conversation information during the period in which the file was corrected. . Then, based on the detection result, it is determined whether or not the correction file including the corrected portion can be applied to the program under software development.

As a result, since the correction file can be applied to the development program when communication is established between the person in charge of development and the expert, it is possible to apply the correction file with high reliability to the development program.

[Second embodiment]
Next, the information processing apparatus according to the second embodiment will be described in detail. FIG. 2 is a diagram showing an example of functional blocks of an information processing apparatus according to the second embodiment. Information processing apparatus 10 includes control unit 11 and storage unit 12 . The control unit 11 includes a conversation information collection unit 11a, a conversation data extraction unit 11b, a conversation data analysis unit 11c, and a conversation presence/absence presentation unit 11d. A communication service system 20 is also connected to the control unit 11 , and the communication service system 20 includes a communication tool 21 and a software development platform 22 .

The communication tool 21 is a conversation tool used for communicating and sharing information, and is, for example, a chat application such as Mattermost or other tools such as e-mail. The software development platform 22 is, for example, a code hosting service such as GitHub.

The conversation information collection unit 11 a collects conversation information from at least one of the communication tool 21 and the software development platform 22 . The conversation data extraction unit 11b extracts conversation data to be analyzed from the collected conversation information.

Based on the extracted conversation data and the history information (development information) obtained from the pull request of the software development platform 22, the conversation data analysis unit 11c identifies the expert, and furthermore, identifies the person in charge of development and the expert. Detect the presence or absence of communication.

The conversation presence/absence presenting unit 11d presents, to the person in charge of software development, a communication presence/absence list indicating whether or not there is communication between the person in charge of development and an expert, and visualized information regarding applicability. The storage unit 12 stores a data structure in which collected/acquired conversation information, history information, and the like are tabulated.

<Hardware>
FIG. 3 is a diagram showing an example of the hardware configuration of the information processing apparatus. The information processing apparatus 10 is entirely controlled by a processor (computer) 100 . The processor 100 has the functions of the control unit 11 .

A memory 101 , an input/output interface 102 and a network interface 104 are connected to the processor 100 via a bus 103 .
Processor 100 may be a multiprocessor. The processor 100 is, for example, a CPU (Central Processing Unit), FPGA (Field Programmable Gate Array), MPU (Micro Processing Unit), DSP (Digital Signal Processor), ASIC (Application Specific Integrated Circuit), or PLD (Programmable Logic Device). is. Processor 100 may also be a combination of two or more of CPU, FPGA, MPU, DSP, ASIC, and PLD.

The memory 101 has the function of the storage unit 12 and is used as the main storage device of the information processing device 10 . The memory 101 temporarily stores at least part of an OS (Operating System) program and application programs to be executed by the processor 100 . Various data required for processing by the processor 100 are stored in the memory 101 .

The memory 101 is also used as an auxiliary storage device for the information processing apparatus 10, and stores OS programs, application programs, and various data. The memory 101 may include, as an auxiliary storage device, a semiconductor storage device such as a flash memory or an SSD (Solid State Drive), or a magnetic recording medium such as an HDD (Hard Disk Drive).

Peripheral devices connected to the bus 103 include an input/output interface 102 and a network interface 104 . The input/output interface 102 can be connected to an information input device such as a keyboard and a mouse, and transmits signals sent from the information input device to the processor 100 . A display is also connected to the input/output interface 102 to display information and the like regarding the conversation presence/absence/applicability determination result.

Furthermore, the input/output interface 102 also functions as a communication interface for connecting peripheral devices. For example, the input/output interface 102 can be connected to an optical drive device that reads data recorded on an optical disc using a laser beam or the like. Optical discs include Blu-ray Disc (registered trademark), CD-ROM (Compact Disc Read Only Memory), CD-R (Recordable)/RW (Rewritable), and the like.

Also, the input/output interface 102 can connect a memory device and a memory reader/writer. The memory device is a recording medium equipped with a communication function with the input/output interface 102 . A memory reader/writer is a device that writes data to a memory card or reads data from a memory card. A memory card is a card-type recording medium.

A network interface 104 is connected to a network and controls the network interface. The network interface 104 accesses the communication service system 20 through the network to collect/acquire conversation information, history information, and the like. The network interface 104 can also use, for example, a NIC (Network Interface Card), a wireless LAN (Local Area Network) card, or the like. Data received by network interface 104 is output to memory 101 and processor 100 .

The processing functions of the information processing apparatus 10 can be realized by the hardware configuration as described above. For example, the information processing apparatus 10 can perform the processing of the present invention by having the processors 100 each execute a predetermined program.

The information processing apparatus 10 implements the processing functions of the present invention by executing a program recorded in a computer-readable recording medium, for example. A program describing the contents of processing to be executed by the information processing apparatus 10 can be recorded in various recording media.

For example, a program to be executed by the information processing device 10 can be stored in the auxiliary storage device. The processor 100 loads at least part of the program in the auxiliary storage device into the main storage device and executes the program.

It can also be recorded in a portable recording medium such as an optical disc, memory device, or memory card. A program stored in a portable recording medium can be executed after being installed in an auxiliary storage device under the control of the processor 100, for example. Alternatively, the processor 100 can read and execute the program directly from the portable recording medium.

<GitHub>
Next, GitHub, which is an example of the software development platform 22, will be described. Git is an open source distributed version control system that is used for source code version control in software development.

A developer creates a development environment (feature branch) copied from the production environment (master branch) when creating a new feature. By merging (integrating) the development-finished branch into the master branch while making commits, the developer can proceed with software development without destroying the master branch, which is the mainstream of development.

Note that a commit is a command that records changes and additions to files together with date/time, executor, differences, comments, etc., and saves the history of file additions and changes in the repository. When the amount of source code changes is large due to the development of a new function, etc., processing is generally divided, and reviewing is facilitated by dividing the processing into commit units.

GitHub is a service that supports software development using such Git, and in addition to source code management, provides pull request services. A pull request is a function to issue a request (request) for incorporating bug fixes and feature additions into the master branch. By making a pull request, it is possible to proceed with software development while checking differences in the source code managed on GitHub.

GitLab, an open source source code hosting system, also has a function called Merge Request, which is equivalent to GitHub's pull request. In this embodiment, a pull request is taken as an example, but similar control is possible for a merge request as well.

FIG. 4 is a diagram for explaining an example of the operation of GitHub.
[Step S11] A new branch (feature branch) is generated by create branch when adding or correcting a source code function to a software development repository serving as a master branch.

[Step S12] Functions are added/corrected to the source code (commit changes), and the feature branch is updated.
[Step S13] A pull request is made to merge the feature branch into the master branch.

[Step S14] Before merging the feature branch into the master branch, feedback verification of function addition/correction is performed.
[Step S15] Final confirmation of the feature branch is performed (test changes).

[Step S16] The feature branch is merged into the master branch (merge branch).
<Operation of Information Processing Device>
Hereinafter, operations of the information processing apparatus 10 will be described in detail. The terms developer, reviewer, and expert are explained here.

The person in charge of development is the person who created the source code of the development function. For example, a person assigned to an assignee on a source code hosting system such as GitHub can be treated as a developer.

A reviewer is someone who checks the source code written by a developer and about to be integrated into the master branch. A person who seems to be familiar with the source code or a person in charge of development (who has the authority to merge into the source code but does not know the source code well) is assigned. For example, a person assigned to a reviewer on a source code hosting system such as GitHub can be treated as a reviewer.

As an expert, for example, a person who has modified source code related to development functions in the past can be treated as an expert. Therefore, a reviewer may be included in an expert, and an expert and a reviewer may overlap.

(Collection of conversation information)
FIG. 5 is a diagram showing an example of conversation information collection operation. Suppose that a conversation c1 takes place with the chat application Mattermost as the communication tool 21 . In conversation c1, sato.hanako responds to yamada.taro's message “Thank you!

The control unit 11 collects semi-structured conversation information cd1 from Mattermost using a REST API (Representational State Transfer Application Programming Interface), a file dump, or the like. Note that REST API is a program calling convention for externally using a web system.

(extraction of conversation data)
FIG. 6 is a diagram showing an example of a conversation data extraction operation. The control unit 11 extracts conversation data required for analysis from the collected conversation information. The extracted conversation data is registered in the chat application table t1.

Chat application table t1 is a table obtained by extracting conversation data from conversation information cd1 collected by Mattermost, and has items of id, original_id, root_id, posted_at, username, channel, and reaction_type.

id is a number identified in the chat application table t1. original_id is a number assigned to one message and corresponds to id in conversation information cd1. "3ot1aijcebf5t8e75kr9text4h" is extracted as the original_id from the conversation information cd1.

root_id is an id (message identifier) attached to a message and corresponds to root_id in conversation information cd1. "3ot1aijcebf5t8e75kr9text4h" is extracted as the root_id from the conversation information cd1.

posted_at is the time when the message was posted, and corresponds to the time converted from the numerical value indicated in create_at in the conversation information cd1. "2020-1221-19:31" is extracted as posted_at from the conversation information cd1.

The username is obtained by converting the user id of the conversation information cd1 into a person's name, and "yamada.taro" is extracted. The channel is a channel name converted from the channel_id of the conversation information cd1, and "team_dev" is extracted. For reaction_type, message is registered when the response to the message is a message, and stamp name is registered when the response is a stamp. In the example of FIG. 6, a stamp name of "smile" is registered as a response to the message "Thank you! I will check this as well."

FIG. 7 is a diagram showing an example of a chat application table. As described above with reference to FIG. 6, the chat application table T1 is a table of conversation data extracted from the conversation information of the chat application Mattermost as the communication tool 21, for example.

In the chat application table T1, each root_id of the conversation data record with id=1 and the conversation data record with id=2 is the same "3ot1aijcebf5t8e75kr9text4h". Conversation data with the same root_id are treated as one and the same conversation thread.

FIG. 8 is a diagram showing an example of a pull request conversation table. The control unit 11 creates a pull request conversation table T2 from GitHub of the software development platform 22 in the same manner as creating the chat application table T1.

The pull request conversation table T2 is a table created by extracting conversation data required for analysis from conversations by issues and pull requests on GitHub, and has items of id, original_id, root_id, posted_at, username, channel, and reaction_type. .

Also, in the pull request conversation table T2, the root_id of the conversation data record with id=1 and the conversation data record with id=2 are the same "dfakjekfjekf5t8e75falejkljsd". In this way, conversation data with the same root_id is treated as one and the same conversation thread in issues and pull requests on GitHub.

In the above, an example of a conversation table created by extracting conversation data from conversation information on Mattermost and GitHub was shown. It is also possible to create a conversation table (meeting remarks table) required.

(Obtain history information)
GitHub has a source code management mechanism in addition to managing the conversation information described above. The control unit 11 acquires history information from the source code management mechanism of GitHub. The history information includes commit information of the master branch and commit information of the development branch (feature branch).

FIG. 9 is a diagram showing an example of data extraction from the commit information of the master branch. The control unit 11 extracts data required for analysis from the commit information of the master branch and creates a master branch update table (production environment update table) t3.

The commit information of the master branch includes master branch update information md1 and commit difference (diff) information md2. The master branch update table t3 registers data extracted from the master branch update information md1 and the commit difference information md2, and has items of id, commitid, username, date and changefile.

id is a number identified in the master branch update table t3. commitid is a number attached to one piece of commit information and corresponds to commit in master branch update information md1. "4c50ff93" is extracted as the commitid from the master branch update information md1.

username is the name of the person who committed to the master branch, and corresponds to Author in the master branch update information md1. "yoshida.jiro" is extracted as the username from the master branch update information md1.

The date is the time when the commit was made and corresponds to the date in the master branch update information md1. "2020-1209-17:16" is extracted as the date from the master branch update information md1.

changefile is the name of the developed file and corresponds to changefile in the commit difference information md2. "fileA" is extracted as a changefile from the commit difference information md2.

FIG. 10 is a diagram showing an example of data extraction from the commit information of the development branch. The control unit 11 extracts data required for analysis from the commit information of the development branch and creates a development branch update table (development environment update table) t4.

The commit information of the development branch includes development branch update information fd1 and commit difference (diff) information fd2. The development branch update table t4 registers data extracted from the development branch update information fd1 and the commit difference information fd2, and has items of id, commitid, username, date and changefile.

id is a number identified in the development branch update table t4. commitid is a number attached to one piece of commit information and corresponds to commit in development branch update information fd1. "bnlrvkrd" is extracted as the commitid from the development branch update information fd1.

username is the name of the person who committed to the development branch, and corresponds to Author in the development branch update information fd1. "sato.hanako" is extracted as the username from the development branch update information fd1.

The date is the time when the commit was made, and corresponds to the date in the development branch update information fd1. "2020-1214-14:33" is extracted as the date from the development branch update information fd1.

changefile is the name of the modified file and corresponds to changefile in the commit difference information fd2. "fileA" is extracted as a changefile from the commit difference information fd2.

(Fixed files, identification of developers and experts)
FIG. 11 is a diagram showing an example of the master branch update table. The master branch update table (production environment update table) T3 is, as described above with reference to FIG. .

FIG. 12 is a diagram showing an example of the development branch update table. The development branch update table (development environment update table) T4 is a table of development data in the development branch extracted from the commit information of the development branch in GitHub, as described above with reference to FIG.

Here, in the examples of FIGS. 11 and 12, the corrected file is detected as fileA based on the changefile column of the development branch update table T4, and based on the username column of the development branch update table T4 of fileA, the correction is performed. The developer involved is identified as sato.hanako.

Then, by narrowing down the changefile column of the master branch update table T3 to records whose value is fileA, it is identified that the experts who have committed to the master branch and created fileA are yoshida.jiro and yamada.taro. be.

Furthermore, the person with the most commits can be identified as the expert most involved in fileA, and the person with the fewest commits can be identified as the person who created the first version of fileA. In this example, yamada.taro is specified as the person who appears most frequently (the person with the highest number of commits) in the username column of the master branch update table T3 (expert person who is most involved in fileA). In addition, yoshida.jiro, which has a small number of commits, is identified as the person who created the first edition.

In this way, the control unit 11 identifies, as an expert, the person who first created the modified file or the person who was most involved in the modification/modification of the modified file in the past, based on the number of commits to GitHub. This makes it possible to identify not only knowledgeable people, but also attributes such as the past most modified files and original authors.

Further, as described above, the control unit 11 acquires history information from GitHub, and from the history information, the name of the creator of the file (username), the creation period (date), and the file name as the update information of the file in the master branch. Create a master branch update table T3 containing (changefile).

Further, the control unit 11 creates a development branch update table T4 including the name of the person who modified the file (username), the modification period (date), and the file name (changefile) as file update information in the development environment from the history information. .

Then, the control unit 11 detects the modified file (fileA) from the file name (changefile) of the development branch update table T4, and detects the person in charge of development (sato.hanako) from the name of the person who modified the file (username). Furthermore, experts (yamada.taro, yoshida.jiro) are detected from the file creator's name (username) in the record in which the detected modified file (fileA) is registered in the file name (changefile) of the master branch update table T3. . Such control makes it possible to accurately identify modified files, developers, and experts from GitHub history information.

(get pull request information)
FIG. 13 is a diagram showing an example of data extraction from pull request information. The control unit 11 acquires pull request information from a code hosting service such as GitHub using REST API. The pull request information includes development related person information (reviewer, developer, etc.), development start date and time when the pull request was opened, and last update date and time.

The pull request information table t5a registers data extracted from the pull request information pr, and has items of id, reviewer, assignee, created_at, updated_at, and pr_id.

id is a number identified in the pull request information table t5a. reviewer is the name of the reviewer, and corresponds to the login name under requested reviewers in the pull request information pr. "saito.goro" is extracted as a reviewer from the pull request information pr.

assignee is the name of the person in charge of development, and corresponds to the login name under assignee in the pull request information pr. "sato.hanako" is extracted as an assignee from the pull request information pr.

created_at is the development start date and time when the pull request was opened, and corresponds to created_at in the pull request information pr. "2020-1210-19:20" is extracted as created_at from the pull request information pr.

updated_at is the date and time when the pull request was last updated, and corresponds to updated_at in the pull request information pr. "2020-1223-13:21" is extracted as updated_at from the pull request information pr. For created_at and updated_at, the time obtained from the system is the Coordinated World Time (UTC: Universal Time Coordinated), so it is set to +9 hours to match with Japan Standard Time.

pr_id is a number that identifies a pull request. It corresponds to the number in the pull request information pr. "48" is extracted as pr_id from the pull request information pr.
It is assumed that conversation data during the period from created_at to updated_at (from 2020-1210-19:20 to 2020-1223-13:21) in the pull request information table t5a is used for analysis. In other words, this period is regarded as the period during which the file was modified, and the presence or absence of communication is detected from the conversation data in this period.

In this way, the control unit 11 extracts the message identifier (root_id) of the conversation message, the conversation time (posted_at), and the name of the speaker (username) from the conversation information collected from Mattermost. Create table T1.

The control unit 11 also extracts the file modification period (from created_at to updated_at) from the pull request information pr when the pull request was opened on GitHub. Then, the conversation thread of the chat application table T1 whose conversation time is included in the file correction period is extracted as the conversation data in the file correction period. This makes it possible to accurately extract conversation data from Mattermost during the period in which the file was modified.

On the other hand, the control unit 11 extracts the message identifier (root_id) of the conversation message, the conversation time (posted_at), and the name of the conversation person (username) from the conversation information collected from GitHub, and creates a pull request conversation table. Create T2.

The control unit 11 also extracts the file modification period (from created_at to updated_at) from the pull request information pr when the pull request was opened on GitHub. Then, the conversation thread of the pull request conversation table T2 whose conversation time is included in the file modification period is extracted as the conversation data in the file modification period. This makes it possible to accurately extract conversation data from GitHub during the period in which files were modified.

FIG. 14 is a diagram showing an example of a pull request related party table. The pull request related party table T5 is obtained by adding an expert column of experts detected from the master branch update table T3 and the development branch update table T4 to the pull request information table t5a. There may be multiple reviewers, assignees, and experts.

(Concrete example of conversation data analysis)
As a specific example of conversation data analysis, it is assumed that the presence or absence of conversation between the person in charge of development and an expert in the development item with pr_id=48 is analyzed. From the pull request related party table T5 shown in FIG. 14, for the development item with pr_id=48, it is detected that the person in charge of development is sato.hanako from the assignee column. Further, it is detected that the reviewer is saito.goro from the reviewer column, and that the experts are yoshida.jiro and yamada.taro from the expert1/expert2 columns. Also, as described above, the conversation data during the period from created_at to updated_at (from 2020-1210-19:20 to 2020-1223-13:21) in the pull request related party table T5 is used for analysis.

FIG. 15 is a diagram showing an example of a chat application table. In the chat application table T11, records with the same root_id are the same conversation thread. Therefore, records with id=1 and 2 where root_id=3ot1aijcebf5t8e75kr9text4h are in the same conversation thread, and records with id=4 and 5 where root_id=mniqwhyhxbn4zfofrxmmjzo1bo are in the same conversation thread.

Here, in the chat application table T11, if there is a conversation thread that satisfies all of the following conditions (1A), (2A), and (3A), it is determined that there was a conversation between the developer and the expert/reviewer.

(1A) Among conversation threads with the same root_id, there is a record with username=developer.
(2A) Among conversation threads with the same root_id, there is a record with username=reviewer or expert.

(3A) Among conversation threads with the same root_id, the username (first speaker/expert) of the row whose posted_at column value is closest to create_at (the row with the oldest posted_at) is a developer, reviewer, or expert. A record exists.

For conversation threads with id=1 and 2 in the chat application table T11, there is a record with username=sato.hanako (developer), so (1A) is satisfied. Also, since there is a record with username=yamada.taro (expert), (2A) is satisfied. Furthermore, since there is a record in which the username (first speaker/expert) of the record with the oldest posted_at in the conversation thread is yamada.taro (expert), (3A) is satisfied.

Therefore, in conversation threads with id=1 and 2, it is detected that there was a conversation between sato.hanako (developer) and yamada.taro (expert).
On the other hand, for the conversation threads with id=4 and 5 in the chat application table T11, there is a record with username=sato.hanako (developer), so (1A) is satisfied. Also, since there is a record with username=yoshida.jiro (expert), (2A) is satisfied. Furthermore, since there is a record in which the username (first speaker/expert) of the line with the oldest posted_at in the conversation thread is yoshida.jiro (expert), (3A) is satisfied.

Therefore, in conversation threads with id=4 and 5, it is detected that there was a conversation between sato.hanako (developer) and yoshida.jiro (expert). With this kind of control, it is possible to accurately detect the presence or absence of communication between the developer and the expert from the chat application table based on Mattermost.

FIG. 16 is a diagram showing an example of a pull request conversation table. In the pull request conversation table T12, records with the same root_id are regarded as one conversation thread. Therefore, records with id=1, 2, 3 with root_id=dfakjekfjekf5t8e75falejkljsd are the same conversation thread.

Here, in the pull request conversation table T12, if there is a conversation thread that satisfies all of the following conditions (1B) and (2B), it is determined that there was a conversation between the developer and the expert/reviewer.

(1B) Among conversation threads with the same root_id, there is a record with username=developer.
(2B) Among conversation threads with the same root_id, there is a record with username=reviewer or expert.

For conversation threads with id=1, 2, and 3 in the pull request conversation table T12, there is a record with username=sato.hanako (developer), so (1B) is satisfied. Also, since there is a record with username=saito.goro (reviewer), (2B) is satisfied.

Therefore, in conversation threads with id=1, 2, and 3, it is detected that there was a conversation between sato.hanako (developer) and saito.goro (reviewer). With this kind of control, it is possible to accurately detect the presence or absence of communication between developers and experts from the pull request conversation table based on GitHub.

(Presence or absence of conversation)
FIG. 17 is a diagram showing an example of a presentation screen for conversation presence/absence. The control unit 11 visualizes the presence or absence of communication between the person in charge of development and the expert/reviewer detected by analyzing the conversation data as described above and the result of merge determination, and presents it to the person in charge of development, for example.

In this case, for example, depending on whether or not the majority of the experts are communicating with the people involved in the development, along with a notification that serves as a criterion for merge judgment such as "Merge OK" or "Merge NG", You may indicate whether or not In addition, a conversation with a person who is not regarded as an expert but has a large amount of conversation may be presented together as a conversation with an expert candidate.

The control unit 11 displays a screen g10. The screen g10 includes screens g11 and g12. Screen g11 represents all the participants in the development items of pull request #48 as nodes, and is a graph that connects the nodes of the developer and the participants with whom the developer spoke with branches. be. sato.hanako (developer) is shown conversing with yamada.taro (expert), yoshida.jiro (expert), suzuki.siro (third party) and saito.goro (reviewer).

A screen g12 shows a conversation presence/absence table T0 and a merge determination result M0. The conversation presence/absence table T0 has items of username, role, and conversation presence/absence. Also, the merge determination result M0 indicates merge OK or merge NG.

From the conversation presence/absence table T0, sato.hanako (developer) is having a conversation with yamada.taro (expert (most revisions)), yoshida.jiro (expert (first edition)), and saito.goro (reviewer). detected. Therefore, the merge determination result M0 as to whether or not to merge (apply) the modified file (modified source code) to the development program is merge OK.

(flowchart)
FIG. 18 is a flow chart showing an example of the operation of the information processing device.
[Step S21] The control unit 11 collects conversation information from communication service systems such as Mattermost and GitHub.

[Step S22] The control unit 11 extracts conversation data required for analysis from the collected conversation information.
[Step S23] The control unit 11 identifies the person in charge of development and the expert/reviewer from the conversation data.

[Step S24] The control unit 11 detects whether or not there is a conversation between the person in charge of development and the expert/reviewer. If there is conversation, the process proceeds to step S25, and if there is no conversation, the process proceeds to step S26.

[Step S25] The control section 11 presents "Merge OK" to the person in charge of development.
[Step S26] The control unit 11 presents "Merge NG" to the person in charge of development.
The processing functions of the information processing apparatuses 1 and 10 of the present invention described above can be realized by a computer. In this case, a program describing the processing contents of the functions that the information processing apparatuses 1 and 10 should have is provided. By executing the program on a computer, the above processing functions are realized on the computer.

A program describing the processing content can be recorded in a computer-readable recording medium. Computer-readable recording media include a magnetic storage unit, an optical disk, a magneto-optical recording medium, a semiconductor memory, and the like. The magnetic storage unit includes a hard disk device (HDD), flexible disk (FD), magnetic tape, and the like. Optical disks include CD-ROM/RW and the like. Magneto-optical recording media include MO (Magneto Optical disk) and the like.

When distributing a program, for example, portable recording media such as CD-ROMs on which the program is recorded are sold. It is also possible to store the program in the storage unit of the server computer and transfer the program from the server computer to another computer via the network.

A computer that executes a program stores, for example, a program recorded on a portable recording medium or a program transferred from a server computer in its own storage unit. Then, the computer reads the program from its own storage unit and executes processing according to the program. The computer can also read the program directly from the portable recording medium and execute processing according to the program.

In addition, the computer can also execute processing according to the received program every time the program is transferred from a server computer connected via a network. At least part of the processing functions described above can also be realized by electronic circuits such as DSPs, ASICs, and PLDs.

Although the embodiment has been exemplified above, the configuration of each part shown in the embodiment can be replaced with another one having the same function. Also, any other components or steps may be added. Furthermore, any two or more configurations (features) of the above-described embodiments may be combined.

1 Information Processing Device 1a Control Unit 1b Storage Unit 2a Correction History Information 2b Communication Service System

Claims (3)

the computer
When the program is modified, based on the modification history information of the program, identify an expert who has experience modifying the program,
Based on the conversation information recorded in the communication service system, determining whether or not there is communication between the developer who modified the program and the expert,
Determining applicability of the modified program based on the result of the determination;
Applicability judgment method. The computer is
Identifying, as the expert, a person who originally created the modified program or a person who was involved in many modifications of the program based on the number of commits to the communication service system;
When it is detected that the communication between the person in charge of development and the expert is established, it is possible to apply the correction program to the program under software development.
Applicability determination method according to claim 1. to the computer,
When the program is modified, based on the modification history information of the program, identify an expert who has experience modifying the program,
Based on the conversation information recorded in the communication service system, determining whether or not there is communication between the developer who modified the program and the expert,
Determining applicability of the modified program based on the result of the determination;
A program that causes an action to take place.

Images