intro done by YY
This commit is contained in:
parent
f3e8e902d4
commit
0fee766192
|
|
@ -2,85 +2,101 @@
|
|||
\section{Introduction}
|
||||
|
||||
%Pull –request
|
||||
The pull-based development model is becoming increasingly popular in distributed collaboration
|
||||
for open source project development~\cite{Barr:2012,Gousios:2014,Gousios:2014b,gousios2016work}.
|
||||
On GitHub~\footnote{\url{https://github.com/}} alone,
|
||||
the largest social coding community, nearly half of collaborative projects
|
||||
The pull-based development model is becoming increasingly popular in distributed collaboration
|
||||
for Open Source Software (OSS) development~\cite{Barr:2012,Gousios:2014,Gousios:2014b,gousios2016work}.
|
||||
On GitHub~\footnote{\url{https://github.com/}} alone,
|
||||
the largest social coding community, nearly half of collaborative projects
|
||||
(already over 1 million~\cite{Gousios:2016} until January 2016) have adopted this model.
|
||||
In the context of pull-based development,
|
||||
In the context of pull-based development,
|
||||
any contributor can freely \emph{fork} (\ie clone) the interested public project
|
||||
and modify the forked repository locally (\eg fixing bugs and adding new features),
|
||||
without asking for the access to the central repository.
|
||||
When the changes are ready to merge back into the master branch,
|
||||
the contributor submit a \emph{pull-request},
|
||||
the contributor submit a \emph{pull-request},
|
||||
and then a rigorous quality evaluation process would be triggered before the pull-request get accepted.
|
||||
|
||||
%Review
|
||||
Integragors(\ie core members of a project) are responsible to review and integrate the submitted changes~\cite{Tsay:2014a,Gousios:2014b,Marlow:2013}.
|
||||
If they doubt about the appropriateness of the problem the pull-request tends
|
||||
to resolve, they can ask the contributors to prove the value of this
|
||||
contribution by showing some use case or just refuse to accept it.
|
||||
If they are not content with the resolution integrators also expect contributors to improve the implementation, sometimes with suggestion,
|
||||
%Review
|
||||
Integrators, core members of a project, are responsible to review and integrate
|
||||
the submitted changes into the main repositories~\cite{Tsay:2014a,Gousios:2014b,Marlow:2013,yu2015wait}.
|
||||
If they doubt about the appropriateness of the problem that the pull-request tends
|
||||
to resolve, they can ask the contributors to prove the value of this
|
||||
contribution by showing some use case or just refuse to accept it.
|
||||
If they are not content with the resolution, integrators also expect contributors
|
||||
to improve the implementation, sometimes with suggestion,
|
||||
or directly provide more excellent alternatives.
|
||||
Occasionally, community audience (neither an integrator or the pull-request submitter) would
|
||||
express their opinions and influence the decision process through community or company support.
|
||||
After receiving the review comments, contributors tend to respond positively and
|
||||
update their pull-request for another round review.
|
||||
Finally, integrators and contributors will reach a consensus after iterative reviews and
|
||||
discussions.
|
||||
With pull-requests becoming increasingly popular,
|
||||
most of large OSS projects enable the crowdsourcing of pull-request reviews
|
||||
to a large number of external developers~\cite{Yu:2015,yu2014reviewer},
|
||||
who are concerned about the development of the corresponding project,
|
||||
to reduce integrators' workload.
|
||||
For a pull-request, those crowd reviewers can help to find potential bugs,
|
||||
add documentations or discuss their opinions with the contributor and core members.
|
||||
After receiving the review comments, the contributor tend to respond positively and
|
||||
update the pull-request for another round review.
|
||||
Finally, the responsible integrator would make a decision that accept the pull-request or reject it,
|
||||
by taking all above judgements and changes into consideration.
|
||||
|
||||
%引出 大目标 -》 小目标
|
||||
%先说 对 comments 的 well understanding 大的贡献是啥， 然后说第一步是先分类
|
||||
%参考 Assessing MCR Discussion Usefulness using Semantic Similarity
|
||||
In this review-driven development process, review comments are of significant research value.
|
||||
Prior research has studied on relationship between number of review comments and
|
||||
pull-request acceptance.
|
||||
To the best of our knowledge, the influence of review comment on reviewer recommendation~\cite{Yu:2015,Thongtanunam:2015,jiang:2015}
|
||||
and pull-request prioritization~\cite{Veen:2015} has not been well understood.
|
||||
%During the evaluation process of pull-request,
|
||||
%In this review-driven development process, review comments are of significant research value.
|
||||
Code Review, the well-established software quality practice,
|
||||
is the most significant stage in the context of pull-based development,
|
||||
to ensure that only high-quality code can be accepted.
|
||||
%This human organized by core team
|
||||
Prior work has show that the code review process exert a great influence on
|
||||
pull-request acceptance~\cite{Tsay:2014b,Yu:2016} and latency~\cite{yu2015wait},
|
||||
and the software release quality~\cite{t2015cq}.
|
||||
Thus, OSS projects need various kinds of tools,
|
||||
\ie reviewer recommender~\cite{Yu:2015,rahman2016correct} and prioritizer~\cite{Veen:2015}
|
||||
to support this process running more efficiently and effectively.
|
||||
|
||||
%To the best of our knowledge, the influence of review comment on reviewer recommendation~\cite{Yu:2015,Thongtanunam:2015,jiang:2015}
|
||||
%and pull-request prioritization~\cite{Veen:2015} has not been well understood.
|
||||
%comments 种类多
|
||||
Various stakeholders are involved in the review process from different perspectives.
|
||||
Familiarity of changed files, understanding of the project’s roadmap,
|
||||
social relationship with the contributor and many other factors
|
||||
influence their focus on the discussion.
|
||||
Some of them care about the
|
||||
contribution appropriateness (\eg whether this contribution is necessary),
|
||||
some pay attention to
|
||||
code quality (\eg perfection of functionality or performance) and
|
||||
some inspect
|
||||
project’s norm consistence (\eg programming convention).
|
||||
% Lots of valuable information is contained in the review comments.
|
||||
|
||||
Our long-term research objective is to improve reviewer recommendation and
|
||||
pull-request prioritization based on the varity of review comments.
|
||||
To investigate this, a necessary first step requires a well understanding
|
||||
of review comments.
|
||||
%Various stakeholders are involved in the review process from different perspectives.
|
||||
%Familiarity of changed files, understanding of the project’s roadmap,
|
||||
%social relationship with the contributor and many other factors
|
||||
%influence their focus on the discussion.
|
||||
%Some of them care about the contribution appropriateness (\eg whether this contribution is necessary),
|
||||
%some pay attention to code quality (\eg perfection of functionality or performance) and
|
||||
%some inspect project’s norm consistence (\eg programming convention).
|
||||
% Lots of valuable information is contained in the review comments.
|
||||
|
||||
%Our long-term research objective is to improve reviewer recommendation and
|
||||
%pull-request prioritization based on the varity of review comments.
|
||||
%To investigate this, a necessary first step requires a well understanding
|
||||
%of review comments.
|
||||
%What we have done
|
||||
In this paper,
|
||||
We frist conduct a case study of three popular open source projects hosted in GitHub,
|
||||
and construct a fine grained multi-level taxonomy for review comments
|
||||
And then,
|
||||
we manually labeled a set of review comments according to the defined taxonomy.
|
||||
Based on this dataset,
|
||||
we proposed a Two-stage Hybrid Classification(\TSHC) algorithm to
|
||||
automatically classifies review comments using rule-based and machine learning (ML) techniques
|
||||
|
||||
In this paper, we conduct a case study of three popular OSS projects hosted in GitHub,
|
||||
to deeply understand the types of review comments from various stakeholders.
|
||||
Firstly, we construct a fine grained taxonomy covering typical motivations that reviewers join the discussion.
|
||||
Then, we manually labeled a large set of review comments according to the defined categories.
|
||||
Based on this dataset, we proposed a Two-stage Hybrid Classification(\TSHC) algorithm to
|
||||
automatically classifies review comments by combining rule-based and machine learning (ML) techniques.
|
||||
%Our contribution
|
||||
% 一个分类体系
|
||||
% 一份标注集
|
||||
% 一个自动分类算法
|
||||
The key contributions of this paper include:
|
||||
The key contributions of this paper includes:
|
||||
\begin{itemize}
|
||||
\item A fine grained multi-level taxonomy for review comments in pull-based development model.
|
||||
\item A dataset of manually labeld review comments which can be accessed via web page~\footnote{https://www.trustie.net/.***} and used in further studies.
|
||||
\item An automatic classification algorithm for reveiew comments.
|
||||
\item A fine grained and multi-level taxonomy for review comments in pull-based development model,
|
||||
relating to technical, management and social aspects.
|
||||
\item A high-quality labeled dataset of review comments, which can be accessed via web page~\footnote{We will publish it after the paper has been accepted.} and used in further studies.
|
||||
\item An high performance automatic classification approach for review comments.
|
||||
\end{itemize}
|
||||
To the best of our knowledge, we are the first to study
|
||||
how to categorize review comments of pull-request in a fine grained level,
|
||||
which is a fundamental work for further studying the best practices
|
||||
in the socialized code review process.
|
||||
|
||||
|
||||
The rest of paper is organized as follows:
|
||||
Section~\ref{sec:bg} illustrates the background.
|
||||
Section~\ref{sec:approach} presents the approach of our study in detail, and
|
||||
The rest of paper is organized as follows:
|
||||
Section~\ref{sec:bg} illustrates the background.
|
||||
Section~\ref{sec:approach} presents the approach of our study in detail, and
|
||||
Section~\ref{sec:result} elaborates the research result.
|
||||
% Section~\ref{sec:Pattern} depicts a preliminary but typical analysis results mined from review comments.
|
||||
% Section~\ref{sec:Pattern} depicts a preliminary but typical analysis results mined from review comments.
|
||||
% Threats and related work can be found in Section~\ref{sec:Threats} and Section~\ref{sec:RelatedW}.
|
||||
Related work can be found in Section~\ref{sec:RelatedW}.
|
||||
Finally, we draw our conclusion in section~\ref{sec:Concl}.
|
||||
|
|
|
|||
42
9_ref.bib
42
9_ref.bib
|
|
@ -1,11 +1,27 @@
|
|||
@article{Yu:2015,
|
||||
title={Reviewer recommendation for pull-requests in GitHub},
|
||||
title={Reviewer recommendation for pull-requests in GitHub: What can we learn from code review and bug assignment?},
|
||||
author={Yu, Yue and Wang, Huaimin and Yin, Gang and Wang, Tao},
|
||||
journal={Information \& Software Technology},
|
||||
journal={Information and Software Technology},
|
||||
volume={74},
|
||||
number={C},
|
||||
pages={204-218},
|
||||
pages={204--218},
|
||||
year={2016},
|
||||
publisher={Elsevier}
|
||||
}
|
||||
|
||||
@inproceedings{yu2014reviewer,
|
||||
title={Reviewer recommender of pull-requests in GitHub},
|
||||
author={Yu, Yue and Wang, Huaimin and Yin, Gang and Ling, Charles X},
|
||||
booktitle={2014 IEEE International Conference on Software Maintenance and Evolution (ICSME)},
|
||||
pages={609--612},
|
||||
year={2014},
|
||||
organization={IEEE}
|
||||
}
|
||||
|
||||
@inproceedings{yu2015wait,
|
||||
title={Wait For It: Determinants of Pull Request Evaluation Latency on GitHub},
|
||||
author={Yu, Yue and Wang, Huaimin and Filkov, Vladimir and Devanbu, Premkumar and Vasilescu, Bogdan},
|
||||
booktitle={MSR},
|
||||
year={2015}
|
||||
}
|
||||
|
||||
@inproceedings{Barr:2012,
|
||||
|
|
@ -92,6 +108,24 @@
|
|||
year={2015},
|
||||
}
|
||||
|
||||
@inproceedings{t2015cq,
|
||||
title={Investigating code review practices in defective files: an empirical study of the Qt system},
|
||||
author={Thongtanunam, Patanamon and McIntosh, Shane and Hassan, Ahmed E and Iida, Hajimu},
|
||||
booktitle={Proceedings of the 12th Working Conference on Mining Software Repositories},
|
||||
pages={168--179},
|
||||
year={2015},
|
||||
organization={IEEE Press}
|
||||
}
|
||||
|
||||
@inproceedings{rahman2016correct,
|
||||
title={CoRReCT: code reviewer recommendation in GitHub based on cross-project and technology experience},
|
||||
author={Rahman, Mohammad Masudur and Roy, Chanchal K and Collins, Jason A},
|
||||
booktitle={Proceedings of the 38th International Conference on Software Engineering Companion},
|
||||
pages={222--231},
|
||||
year={2016},
|
||||
organization={ACM}
|
||||
}
|
||||
|
||||
@article{jiang:2015,
|
||||
title={CoreDevRec: Automatic Core Member Recommendation for Contribution Evaluation},
|
||||
author={Jiang, Jing and He, Jia Huan and Chen, Xue Yuan},
|
||||
|
|
|
|||
Loading…
Reference in New Issue