陳 萍，程逸凡

(1.南京醫(yī)科大學 圖書館，江蘇 南京 211166；2.南京郵電大學，江蘇 南京 210046)

0 引言

大數(shù)據(jù)、區(qū)塊鏈、人工智能、5G等新技術的迅猛發(fā)展，為高校圖書館的現(xiàn)代化轉型發(fā)展帶來了契機。針對科技浪潮對高校師生信息與服務需求在先進性、知識化、便捷化和智能化等方面帶來的巨大變革，高校圖書館應主動積極融合各項新技術，以用戶需求和偏好為導向[1]，運用開源資源研發(fā)圖書館應用系統(tǒng)。2020年在美國得克薩斯農工大學舉辦了世界開放圖書館基金會會議[2](World Open Library Foundation Conference，WOLFcon)，會上眾多倡導開源運動的圖書館、開發(fā)人員、相關學者和開發(fā)商聚集在一起，共同對開源軟件在圖書館的運用開展了深入的探討，提出發(fā)展前景。高校圖書館可以此為契機，運用開源軟件以適應新技術的發(fā)展趨勢滿足高校師生對圖書館的智慧服務需求。

本文針對高校圖書館運用基于GitHub開源軟件進行應用系統(tǒng)開發(fā)存在的制約因素(Pull Request被拒絕)，通過數(shù)據(jù)挖掘的關聯(lián)規(guī)則，對GitHub上影響Pull Request被拒絕的影響因素進行了深入分析，并提出解決辦法，為高校圖書館開源項目深入研發(fā)和應用提供技術支撐，提升高校圖書館數(shù)字服務能力。

1 相關技術的提出

版本控制系統(tǒng)(Version Control System)是配置管理的主要策略之一，允許開發(fā)人員通過開發(fā)和維護來控制對軟件工件的更改[3]。分布式版本控制系統(tǒng)(Distributed Version Control System)的出現(xiàn)，則增強了支持協(xié)作軟件開發(fā)的模式[4]，分布式版本控制系統(tǒng)使開發(fā)人員可以控制多個遠程存儲庫，從而使不同小組可以同時在同一項目上進行聯(lián)合工作。這種系統(tǒng)的一個例子是Git，它記錄了軟件發(fā)展的整個歷史。這樣，項目托管工具被視為豐富的信息源，以支持配置管理過程。分布式版本控制系統(tǒng)的一個重要功能是系統(tǒng)化外部團隊成員如何與核心團隊成員進行協(xié)作[5]。外部成員可以克隆存儲庫，更改代碼，然后請求將更改合并回主存儲庫。請求將更改合并回存儲庫的過程是通過Pull Request完成的，Pull Request中包含的貢獻將由負責其分析的核心團隊的任何成員選擇接受或拒絕。

當前，GitHub被廣泛用于軟件開發(fā)行業(yè)[6]，它是一種流行的分布式版本控制系統(tǒng)，用于開源項目中的源代碼管理和控制。在GitHub中，Pull Request是代碼貢獻的首選方法[7]，當開發(fā)人員希望將其代碼更改合并到項目的主存儲庫中時，將提交Pull Request[8]。Pull Request狀態(tài)有兩種：接受和拒絕。Pull Request狀態(tài)指示將源代碼合并到主存儲庫中的權限。然而，GitHub上提交的大部分Pull Request事務都會被拒絕，這將會對開發(fā)項目和開發(fā)人員產生影響。被拒絕之后他們需要花費更多的精力來修改并重新提交Pull Request，等待提交的Pull Request被接受。如今，GitHub上有許多被拒絕的Pull Request事務，這將影響項目時間表和開發(fā)人員的工作，他們需要編輯或更改其代碼，直到Pull Request被接受。

本文在分析GitHub開源開發(fā)模式的Pull Request被拒絕的因素過程中，考慮了社會關系、是否第一次進行Pull Request、刪除計數(shù)、新增計數(shù)、提交計數(shù)、代碼更改計數(shù)和Pull Request流程持續(xù)時間等諸多因素, 利用關聯(lián)特征和關聯(lián)規(guī)則中最常用的Apriori算法, 使用關聯(lián)規(guī)則發(fā)現(xiàn)影響因素之間的關系，并將這些影響因素添加到組織或開源項目的編碼指南中，成為開發(fā)人員將其代碼更改合并到主存儲庫之前驗證源代碼的清單，以幫助開發(fā)人員提交的Pull Request盡量避免被拒絕。

2 影響開源項目中Pull Reguest合并結果的研究現(xiàn)狀

Soares等[4]提出了在數(shù)據(jù)挖掘中使用關聯(lián)規(guī)則方式找到影響因素。對于影響Pull Request的因素，他們采用了一種稱為關聯(lián)規(guī)則提取的數(shù)據(jù)挖掘技術來尋找影響因素。他們使用了GHTorrent工具，該工具從GitHub中提取信息，并設置10個屬性作為數(shù)據(jù)的關鍵。對于在接受率高的軟件項目中發(fā)現(xiàn)核心團隊開發(fā)人員處理的Pull Request拒絕因素的解決方案，他們提出了一項關于增加核心團隊成員處理的Pull Request被拒絕的研究。

Gousios等[9]和Soares等[4]都關注接受因素。前者關注評審者的視角，后者則應用定量技術提取關聯(lián)規(guī)則，從而獲得Pull Request認可。相反，本文主要關注被拒絕的Pull Request，以建立對拒絕原因的理解，通過應用定量方法來捕捉拒絕原因。

Terrell等[10]分析并討論了接受Pull Request時的性別偏見。

Steinmacher[11]調查了Pull Request拒絕的原因。(1)詢問了作者對他們的Pull Request被拒絕的原因的看法。(2)能夠根據(jù)作者的意見建立一份拒絕理由清單。(3)交叉分析了拒絕原因列表，并對Pull Request數(shù)據(jù)集的一個子集進行手動分析。本研究采取了不同的方法。本文沒有直接手動分析公關和調查公關作者，而是通過數(shù)據(jù)挖掘應用定量提取關聯(lián)規(guī)則，并考慮了來自各種貢獻者(內部和外部)的Pull Request。

3 挖掘影響開源項目中Pull Request被拒絕的方法主體

3.1 選擇開源項目

獲取多個GitHub開源項目數(shù)據(jù)集，本文選擇Pull Request數(shù)量多的項目。獲取多個星星數(shù)高的受歡迎的GitHub開源項目數(shù)據(jù)集，其中包括項目名稱以及倉庫名稱、項目中具體的Pull Request 數(shù)量、項目的貢獻者數(shù)量和星星數(shù)量。開源項目集如表1所示。

表1 Pull Request項目數(shù)據(jù)集

3.2 收集相關因素

通過兩種方法可以找到相關的Pull Request評審結果因素：分析Pull Request上的標簽和從相關工作中找到因素。標簽是一個小的關鍵字，附加到Pull Request，并給出有關它的信息。Pull Request標簽一般有兩種類型:工作流標簽和信息標簽。工作流標簽是識別Pull Request狀態(tài)的關鍵，如合并、工作進行中等。信息標簽是標識Pull Request一些有用信息的標簽，如標識Pull Request的描述信息、標識Pull Request的平臺等。信息標簽也作為相關因素被應用。

許多相關的工作已經確定了GitHub上的Pull Request或代碼評審因子。由于代碼質量是識別Pull Request狀態(tài)的關鍵，本研究中使用的相關工作中的多種因素不僅包括在GitHub上的Pull Request或代碼審查，還包括代碼質量指標，這些因素包括項目名稱、Pull Request Ids、Pull Request是否合并、貢獻者經驗度、貢獻者是不是第一次Pull Request、貢獻者的社會關系、Pull Request描述相關信息、貢獻者評論、Pull Request過程持續(xù)時間、Pull Request過程中評審者評論、文件修改數(shù)量、代碼行增加數(shù)量、代碼行刪除數(shù)量、信息提交數(shù)量和Pull Request使用編程語言。這些因素的總結和描述如表2所示。

表2 相關因素總結和描述

3.3 選擇算法和指標類型

Weka上提供了3種關聯(lián)算法:Apriori、FilteredAssociator和FPGrowth。Apriori算法是本文所采用的算法。Apriori算法在給定的最小置信度下，不斷減少最小支持度，直到完成所需規(guī)則數(shù)，其使用了基于給定支持度的剪枝手段，從而限制候選項集的指數(shù)級增長。

Apriori算法采用了逐層迭代的方法，先搜索出候選1項集及對應的支持度，剪枝去掉低于支持度的1項集，得到頻繁1項集。然后對剩下的頻繁1項集進行連接，得到候選2項集，篩選去掉低于支持度的候選2項集，得到頻繁項集，以此類推，迭代下去，直到無法找到頻繁k+1項集為止，對應的頻繁k項集的集合即為算法的輸出結果。

置信度、提升度、杠桿度和確定度是Apriori算法中的度量指標類型。為了發(fā)現(xiàn)影響因素之間的關系，需要使用指標度量類型，它是對關聯(lián)規(guī)則進行排序的分數(shù)。置信度和提升度是本文研究選擇的指標度量類型。

置信度Conf(Confidence)是本研究選擇的第一個評估指標，計算置信度需要先計算另一個指標支持度Sup(support)。指標支持度Sup定義為滿足前因條件的條件數(shù)量占數(shù)據(jù)庫中總記錄數(shù)的百分比。支持度Sup計算如下：Sup(X→Y)=T_(x∪y)/T，其中T_(x∪y)表示數(shù)據(jù)庫D中同時滿足條件X和條件Y的記錄數(shù)量，T表示D中的總記錄數(shù)量。置信度指標表示在前因事件發(fā)生的基礎上后因事件發(fā)生的概率。置信度Conf計算如下：Conf(X→Y)=T_(x∪y)/T_x，其中T_x表示數(shù)據(jù)庫D中滿足條件X的記錄數(shù)量。

在本文研究中考慮的另一個評估指標是提升度Lift，它表明在事件X發(fā)生的情況下，對事件Y條件發(fā)生概率的提升程度。Lift計算為規(guī)則的置信度與其結果支持度的商，提升度計算如下：Lift(X→Y)=Conf(X→Y)/Sup(X)。當Lift=1時，事件X和事件Y之間存在條件獨立性，也就是說，前因事件X不干擾后因事件Y的發(fā)生。另一方面，Lift>1表示前因事件和后因事件之間存在正相關性，這意味著X事件的出現(xiàn)增加了Y事件的發(fā)生概率。相反，當Lift<1時，前因事件和后因事件之間存在負相關性，這表明前因事件X的發(fā)生反而降低了后因事件Y的發(fā)生概率。在本次研究中，興趣度量(支持度、置信度和提升度)用于評估規(guī)則的相關性，這些規(guī)則指示了影響Pull Request合并失敗的因素。

3.4 數(shù)據(jù)預處理

GitHub存儲了開源項目的所有信息，不僅包括源代碼，還包括圖像、文檔等，它是一個分布式的版本控制系統(tǒng)，需要存儲開源項目的所有信息。本論文使用的數(shù)據(jù)發(fā)生時間參考到2021年10月的統(tǒng)計，因為分析的數(shù)據(jù)應該與本論文統(tǒng)計結果相關。Pull Request數(shù)據(jù)應該只發(fā)生在2021年10月之前。預處理數(shù)據(jù)有3個步驟:刪除異常值，解決一些一致性和刪除非編碼的Pull Request。刪除異常值，因為分析的因素需要統(tǒng)一類型的數(shù)據(jù)，所以刪除了與統(tǒng)一數(shù)據(jù)類型不同的異常數(shù)據(jù)，例如刪除非整數(shù)的數(shù)據(jù)變動數(shù)并刪除整條Pull Request的數(shù)據(jù)記錄。刪除非編碼的Pull Request，因為分析的數(shù)據(jù)需要分析和查找每個因素的值，所以判斷過濾了其中沒有進行代碼變動的Pull Request，刪除非編碼的Pull Request。

4 研究結果分析

在完成相關因素的收集和處理后，將它們按照一條Pull Request的相關因素數(shù)據(jù)排列為一行的文本文件，將13多萬條Pull Request信息處理輸出為13行分類數(shù)據(jù)的文本作為后面實驗的輸入數(shù)據(jù)。部分相關因素如圖1所示。

圖1 Pull Request準備數(shù)據(jù)圖

發(fā)現(xiàn)關聯(lián)規(guī)則首先需要從數(shù)據(jù)集資料集合中找出頻繁項集，頻繁項的意思是某個項目組出現(xiàn)次數(shù)占比總記錄數(shù)高于一個頻繁設定標準，頻繁項集則是所有頻繁項的集合。某個項目組出現(xiàn)次數(shù)的頻率稱為支持度Sup，可以通過公式Sup(X)=T_x/T來求得項目組X的支持度，若支持度Sup大于等于所設定的最小支持度門檻值時，則稱為頻繁項。本文中設置最小支持度門檻值為0.25，由設置的最小支持度門檻值可以在準備數(shù)據(jù)中找出所有的頻繁項集。通過找出的頻繁項集來產生關聯(lián)規(guī)則。一個滿足最小支持度的k頻繁項，可以稱為高頻k-頻繁項，從頻繁項集中產生關聯(lián)規(guī)則，是利用前一步驟的高頻k-頻繁項來產生規(guī)則，在最小置信度的條件門檻下，若一規(guī)則所求得的置信度滿足最小置信度，稱此規(guī)則為關聯(lián)規(guī)則。在本研究中設置最小置信度的條件門檻為0.5，由設置的最小置信度在頻繁項集中提取影響Pull Request合并失敗的關聯(lián)規(guī)則，提取規(guī)則有四列，描述了表3中影響Pull Request失敗的相關因素關聯(lián)規(guī)則：規(guī)則表示規(guī)則編號，提取規(guī)則表示前后規(guī)則的發(fā)生模式；Conf表示各規(guī)則的置信度；Lift表示各規(guī)則的提升度。根據(jù)分析結果提取出的關聯(lián)規(guī)則，由此得出提交的Pull Request被拒絕的影響因素以及影響的程度。

表3 關聯(lián)規(guī)則

5 結語

本文針對高校圖書館在進行開源項目開發(fā)中出現(xiàn)的技術難點，利用數(shù)據(jù)挖掘關聯(lián)規(guī)則，發(fā)現(xiàn)最密切影響開源項目中Pull Request被拒絕的影響因素是Pull Request評論過多、貢獻者以前的Pull Request貢獻度低、代碼行刪除數(shù)量過多、Pull Request描述相關信息過多、Pull Request過程持續(xù)時間過長、代碼行增加數(shù)量過多、信息提交數(shù)量過少。文章提出幫助開發(fā)人員提交的Pull Request盡量避免被拒絕的方法，為高校圖書館在開源項目的開發(fā)和實施提供參考，努力促成圖書館領域現(xiàn)代技術生態(tài)系統(tǒng)的形成，在助力高校圖書館“十四五”期間現(xiàn)代化進程和跨越式轉型發(fā)展[12]的同時，進一步推動高校圖書館由智能服務轉向智慧服務。