starlee
/
prj_doc
0
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

minor changes

This commit is contained in:
whystar 2020-09-06 18:02:56 +08:00
parent 6ae2e31bc3
commit bcb2a580c8
3 changed files with 14 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
2_background.tex
View File

@ -6,7 +6,7 @@ After years of development,
GitHub has synthesized various functionalities for OSS development,
such as hosting source code, tracking issues~\cite{bissyande2013got}, and submitting pull requests~\cite{Gousios:2014}.
An increasing number of developers are collaborating on GitHub,
which makes GitHub be the main platform for community-based collaboration.
which leads GitHub to be the main platform for community-based collaboration.
As aforementioned,
profile documentation is crucial for OSS communities to operate and survive.
However,

10
3_method.tex
View File

@ -22,7 +22,7 @@ we looked for its existence in each project and computed its prevalence in all t
Then, we grouped all the projects by programming language and repository owner, respectively,
and computed documentation prevalence in different groups.
Finally,
for each kind of documentation
for each kind of documentation,
we classified projects into two groups according to whether they include the documentation,
and compared the distribution of repository age and community size between two groups, respectively.
@ -31,7 +31,7 @@ and compared the distribution of repository age and community size between two g
\textbf{RQ2. Documentation maintenance.}
How is the community profile documentation maintained?
Specifically,
what are the location, creation, maintainers, update frequency and change-triggering events of community profile documentation?
what are the location, creation time, maintainers, update frequency and change-triggering events of community profile documentation?
To answer this question,
we first extracted the parent directory of community profile documentation, and computed the occurrence frequency of different locations for each kind of documentation.
@ -48,7 +48,7 @@ The dataset used in this paper includes 2,000 OSS projects hosted on GitHub.
The following sections present the details about how we obtained these projects and how we identified the community profile documentation and their change history from these projects.
\subsubsection{Studied projects}
We randomly selected 2,000 GitHub non-fork public repository using GitHub API (\url{https://api.github.com/search/repositories?q=[search\_criteria]}) which returns repositories based on the search criteria.
We randomly selected 2,000 non-fork public repository using GitHub API (\url{https://api.github.com/search/repositories?q=[search\_criteria]}) which returns repositories based on the search criteria.
In our API calls,
the criteria comprises two parts:
@ -59,14 +59,14 @@ the criteria comprises two parts:
(\ie developers first \textit{fork} the repository of a project, then make changes based on the forked repository, and finally send a pull-request to notify the project maintainers to \textit{pull} the submitted changes).
Therefore, the number of forks can be used as a measure of the community size of an OSS project,
\ie the more forks a project has,
the larger its community is.
the larger its community.
We consider a project with more than 2 forks may have formed its own community.
\item \textit{Random effect} (\texttt{created:\%s..\%s}):
The API can only return 1,000 search results at most in total.
Consequently,
we cannot first get all the repositories with more than 2 forks and then randomly get a sample from them.
it is impossible to first get all the repositories with more than 2 forks and then randomly get a sample from them.
To tackle this issue,
we achieved the random effect on each individual API call.
Specifically,

16
4_1.tex
View File

@ -9,8 +9,8 @@ by programming language, repository owner type, repository age, and community si
Table~\ref{tab:pop_over} lists the percentage of repositories
including community profile documentation.
We can see that \RDM and \LIC documentation is significantly more popular than the others,
which are included by 99.2\% and 81.1\% of projects, respectively.
We can see that the \RDM and \LIC documentation is significantly more popular than the other kind of documentation,
which is included by 99.2\% and 81.1\% of projects, respectively.
This may be because developers tend to follow the practice recommended by GitHub to automatically include a \RDM file and a \LIC file when creating a new repository,
as shown in Figure~\ref{fig:new_repo}.
@ -25,7 +25,7 @@ as shown in Figure~\ref{fig:new_repo}.
Surprisingly,
\CON documentation has a low percentage of inclusion,
the \CON documentation has a low percentage of inclusion,
which is only included by 26.45\% of repositories.
One possible explanation is that
some projects already include information about contributing guideline in the \RDM documentation~\cite{Prana2018Categorizing},
@ -34,9 +34,9 @@ The effectiveness of including a separate \CON file rather than mixing the relat
Similarly,
\TMP documentation is included by 23.65\% of projects.
the \TMP documentation is included by 23.65\% of projects.
This means that quite a number of OSS maintainers do not
formulate a policy about the information provided by
formulate a policy about the information that should be provided by
developers when reporting issues or submitting pull requests.
We speculate that OSS maintainers might avoid putting too much burden on contributors, and they hope to make the issue-reporting and patch-submitting processes more lightweight and straightforward.
Otherwise,
@ -44,7 +44,7 @@ too tedious processes might hinder contributors' motivation to participate~\cite
At last,
we note that \COD documentation has an extremely low percentage of inclusion,
we note that the \COD documentation has an extremely low percentage of inclusion,
\ie only 10.95\% of projects include a \COD file.
This might be due to the viewpoint that
OSS developers are mature enough to behave well and deal with debates and differences~\cite{Tourani2017Code},
@ -102,8 +102,8 @@ the highest percentages of documentation inclusion are all observed in
TypeScript repositories,
which indicates that maintainers of TypeScript repositories are more inclined to follow the practice recommended by GitHub.
At last,
C, PHP, and Ruby have the lowest percentage of repositories including
\CON, \COD, and \TMP, respectively.
C, PHP, and Ruby have the lowest percentage of repositories including the
\CON, \COD, and \TMP documentation, respectively.