% new para2
The experiments of this paper use the static code features of 10 projects tabulated in \tbl{data1} and \tbl{data2}, which are
downloaded from the PROMISE repository\footnote{\url{http://promisedata.org/repository}}.
Available static code features are shown in \tbl{attr1}. 
%(and explained in  \fig{halstead} and \fig{mccabe}).  
%Defect predictors have been successfully learned from wide variety of measures such as:
%\bi
%\item static code features~\cite{me07b};
%\item churn metrics (rates of code change)~\cite{nikora03};
%\item personnel details about the development team~\cite{nach08};
%\item features extracted from requirements documents~\cite{jiang07}.
%\ei
%This list is hardly exhaustive and can be extended be either adding
%new feature types
%of combining existing ones.
%For example,  Jiang, Cukic \& Menzies~\cite{jiang07} found that
%defect predictors learned from
%requirements {\em and} code measures can create predictors that out-perform predictors learned
%from just code {\em or} just requirements metrics. 
%Nevertheless, we hesitate to demand defect prediction should {\em always} be based on 
%churn, requirements, code, or personnel features.
%We have some theoretical evidence suggesting that the ``best'' set of features
%may change from project to project (see the  feature subset selection experiments of
%\cite{me07c}).
%More pragmatically, we note that
%different projects use different tools and build software
%using different processes. Hence, different projects have access to
%different sets of features which may be useful for predicting where
%faults hide; for example:
%\bi
%\item An open source software (OSS) or agile process may have no access to the
%detailed requirement documents used to build model by Jian, Cukic, \& Menzies;
%\item The data used in this study (see \tbl{data}) comes 
%from NASA sub-contractors who do not report
%the personnel information used by Nagappan et.al. in their defect predictions~\cite{nach08}.
%\ei
%Debates over the value of one kind of feature over another is 
%orthogonal to the main point of this paper.
%In this work, we identify a particular type of feature (i.e. static code features) 
%which we can collect from multiple projects. With that data in hand, we now explore
%the value of CC vs WC learning. For future work, we would repeat this analysis
%with those other kinds of features, if and when they become available from multiple projects.
An advantage of static code features is that they can be quickly and automatically collected
from the source code, even if no other information is available.
%We considered using static code features collected from OSS and examined
%the defect logs of the Mozilla project. 
%This experiment was abandoned when we realized that, at least for the Mozilla project,
%that those issue reports did not accurately map between defect reports and modules;  e.g. 
%a developer may checking many modules as part of a bug fix, some of which may actually
%be enhancements generated as a side-effect of the bug fix.
%Other researchers have had more success with OSS defect prediction~\cite{kim08}
%and in future work we will try again to apply
%our methods to OSS.