|
1.1: Motivations
|
Multiple choices possible |
|
| b. The project was started primarily to produce software to
support another Open Source/Free Software project |
| e. The project's intention from the beginning was to produce
at least part of its software as Open Source/Free Software. |
| f. The project began based on pre-existing Open Source/Free Software (code
fork, etc.). |
| |
|
1.2: User Base
|
Multiple choices possible |
|
| a. Yourself. |
| b. The project team |
| g. The Free Software/Open Source community. |
| h. The computing community. |
| i. Other: People interested in Scheme and the idea of an extension/scripting language. |
Comment:
Guile is a programming language implementation and the people using it are hard to categorize. |
| |
|
1.3: Project age
|
Single choice |
|
| d. 2-5 years |
| |
|
1.4: Pre-existing standard
|
Single choice |
|
| a. Yes. |
Comment:
R5RS for Scheme.
SRFIs for extensions to Scheme.
See www.schemers.org.
GNU coding standards. |
| |
|
2.1: Team size
|
Single choice |
|
| c. 6-15 |
| |
|
2.2: Leadership model
|
Single choice |
|
| b. The project has a single leader, which delegates responsibility
occasionally to others. |
Comment:
We used to have a group of leaders but now only a single one is left effectively. |
| |
|
2.3: General team aspects
|
Multiple choices possible |
|
| a. Most people in the team know each other only through the Internet,
and have never met physically/personally. |
| c. The team includes people that have more than 5 years experience in
serious software development. |
| e. A contributor to the project will often participate in more than
one project activity: functionality definition, architectural
design, designing user interfaces , coding, testing, project
management, etc. |
| |
|
3.1: Defining Functionality
|
Multiple choices possible |
|
| b. A significant amount of effort is spent defining what the
software functionality and behavior (the requirements) should be. |
| d. There have been meetings or discussions with end-users to define
significant parts of the software functionality or behavior. |
| |
|
3.2: Usability
|
Multiple choices possible |
|
| (Left unanswered) |
| |
|
3.3: Documentation
|
Multiple choices possible |
|
| a. We have produced documents that describe at least some of the
expected functionality and behavior (requirements) of our
software. |
| c. There is a reasonably complete coding standards guide that is
actively followed by the team. |
| d. There is documentation for the end-user available for the project's
software (consider also third-party documents available). |
| f. A significant part of the available documentation is frequently
updated and revised to be up to date. |
Comment:
The documentation exists and is kept uptodate but parts are still missing. |
| |
|
3.4: Quality Assurance
|
Multiple choices possible |
|
| a. There is an [automated] test suite for the project's software, that
is used to validate it. |
| c. Periodic (i.e. nightly, weekly) snapshots of the project's code (or
binaries) are distributed and used as an significant means of testing
the software. |
| g. There is a tendency (or policy) to release a public version only
when it has been extensively tested by the team. |
| |
|
3.5: Tools
|
Multiple choices possible |
|
| a. A project hosting site such as Sourceforge.net, Savannah or
Collab.net (mark all others applicable as well) |
| b. One or more Web sites |
| d. A Frequently Asked Questions document |
| e. A version control tool such as CVS, RCS, Subversion or Bitkeeper |
| g. One or more mailing lists |
Comment:
We have a FAQ but it is old. |
| |