57 lines
3.2 KiB
TeX
57 lines
3.2 KiB
TeX
|
||
\section{Conclusion} \label{sec:cc}
|
||
%%%fixed %%% conclusion关于rq需要重写一下，不能是rq1,rq1,rq3, 而是需要面向问题本身(the negative impact of duplicate pull requests,
|
||
In this study,
|
||
we investigated the problem of duplicate contributions in the context of pull-based distributed development.
|
||
The goal of our study is to better understand
|
||
the influences of duplicate pull requests during collaborative development,
|
||
the context in which duplicate pull requests occur,
|
||
and the alternative preference of integrator between duplicate pull requests.
|
||
%We conducted an empirical study and answered three research questions
|
||
%based on a dataset of duplicate pull requests collected from GitHub.
|
||
We conducted an empirical study on 26 GitHub projects to achieve the goal.
|
||
We found that
|
||
duplicate pull requests slow down the review process and require more reviewers for extended discussions.
|
||
We observed that duplicate pull requests are significantly different from non-duplicate pull requests in terms of project-level characteristics (\eg area hotness and number of active core team members),
|
||
submitter-level characteristics (
|
||
\eg contribution experience and social connection to project),
|
||
and patch-level characteristics (
|
||
\eg change type and issue visibility).
|
||
% contributors' experience, modification type, modification size, modification hotness, issue visibility, and file type.
|
||
We found that duplicate pull requests with accurate and high-quality implementation, broad coverage, necessary test codes, high maturity, and deep discussion, are more likely to be accepted.
|
||
We also found that integrators might make a choice based on non-technical considerations,
|
||
\textit{e.g.},
|
||
they may accept pull requests to encourage newcomers or respect arrival order and active response.
|
||
|
||
|
||
Based on the findings
|
||
%%%we also propose some practical suggestions.
|
||
%we made practical suggestions.
|
||
we recommend that
|
||
OSS contributors should always perform sufficient verification against
|
||
existing work before they start working on a task.
|
||
%Moreover,
|
||
Contributors are expected to declare their intentions as soon as possible
|
||
and prepare their work with complete related information to
|
||
make their work highly visible early on.
|
||
Intergrators should provide detailed explanation and constructive suggestions
|
||
when they reject duplicate pull requests,
|
||
which helps form a friendly environment and retain contributors.
|
||
Social coding platforms are expected to enhance
|
||
the awareness mechanisms
|
||
in order to make it more effective and efficient for developers to stay aware of each other.
|
||
It is also meaningful to provide practical service and tools to support
|
||
automatic identification of duplicates,
|
||
visualized comparison between duplicates, \etc.
|
||
|
||
|
||
Last but not least,
|
||
our findings point to several future research directions.
|
||
Researchers can design awareness tools to increase developers' awareness of others’ activities.
|
||
Such tools not only help prevent duplicate effort on the same tasks
|
||
but also have the potential functionality to link related contributors for better coordination.
|
||
Moreover,
|
||
we think it is meaningful to investigate
|
||
how integrators' practices in managing the contributors' conflicts
|
||
affect contributors' continuous participation.
|