Hardware Reference
In-Depth Information
Task
Description and Evidence Sources
Promote actively
contributing members
of the community to
committers
Community members who provide valuable contributions
to the project over a period of time often receive rights to
contribute directly to a project's code repository.
Instances of this process can sometimes be seen on a
project's development mailing lists.
Review changes by
committers
In some projects, changes proposed by developers with
direct commit rights are also subject to review by other
community members. This type of peer reviews can sig-
nificantly contribute to code quality.
This process can be evaluated by looking at the
project's change log files or at the log messages written
when committing changes to the code repository.
Propose significant
enhancements
Some projects have disciplined processes that allow
community members to formally propose enhancements
for discussion by the community.
Enhancement proposals may take many forms, includ-
ing web pages, Wiki pages, and messages submitted to a
mailing list or forum.
Report and handle
issues with the
product
For obvious reasons, this process is present in almost
all Open Source projects in some form or another.
Except for very small projects, this task is normally
supported by an issue tracking system, in which case
process instances correspond to the reports in the system,
as well as their accompanying discussions. Small projects
may handle this through a mailing list, in which case in-
stances are the messages reporting the problem and the
discussions following it.
Test the program or
programs produced
by the project
Most projects doing repeatable testing do it by defining
an automated test suite. If no test suite is available, there
may be explicitly defined manual test cases, but this is
much less likely to happen. Test suites and defined test
cases are normally part of the source code and can be
found in the code repository. Instances of this process are
test reports, either created automatically by running the
test suite or manually.
Decide at which point
in time a release will
be made.
Either releases are done on a time-based fashion or based
on a feature “road map”. Instances of any of these two
documents can often be found as part of a project's web
or Wiki pages, or, occasionally, as messages to a certain
mailing list or forum.
