Hardware Reference
In-Depth Information
1.
Not applicable:
no documented process, no consistent process.
2.
Low agreement:
low agreement between documentation and established practice.
3.
High agreement:
high agreement between documentation and established practice.
The fifth and final question is concerned with how adequate the process is for the task it
is intended for. This is, of course, a difficult question, not only because it is specific to
each particular task, but because experts often disagree regarding the practices that are
appropriate for a certain task. Our approach to handling this problem is to provide a list
of additional questions that address the specificities of every task. These questions are
normally not comprehensive, but provide a minimum checklist that helps to make sure
that essential aspects of the corresponding process are being taken into account. We see
these questions only as complementary to the first four assessment questions, because,
clearly, if a process is established in the sense defined above, it is probably adequate to a
certain measure, given how pragmatic OSS communities usually are.
4.3 Process Areas Currently Covered by QualOSS
As already mentioned, the QualOSS process evaluation covers a number of software
development related tasks that are usually important for the success of an OSS pro-
ject. The following table lists the tasks that are currently covered (left column) and
provides a brief description for each of them, together with some information about
where their process data trail could be found (right column). This is just an initial se-
lection of tasks, which we are likely to extend as we gain experience with the process
evaluation.
Task
Description and Evidence Sources
Change submission
Submit changes (e.g., defect corrections, enhancements),
typically in the form of so-called patch files, to the pro-
ject for potential inclusion. This task is restricted to
changes proposed by community members who do not
have commit rights to the main project versioning reposi-
tory, and thus cannot change the project's code directly.
Common methods used to submit changes include
sending them to a mailing list, putting them in an issue
tracking system, or, more recently, publishing modified
code using a distributed version control system. After
identifying the method used by a project, individual
change submission instances can be studied using the
generic evaluation procedure.
Review changes
submitted by the
community
This task is complementary to the previous task, namely,
changes submitted by community members must be re-
viewed and either rejected with an appropriate justifica-
tion, or accepted and integrated into the project's main
code repository.
This task can be analyzed in a way similar to the pre-
vious task.
