7.1 Contributing to Monod

Contributions to the Monod project are welcome in all possible forms: discussions, critiques, documentation, support, coding, etc. The only rule is that the project should be kept as fun and ambitious as it is now! This section describes how to best contribute to the project.

The first thing to do is to get in touch with the project maintainer. Write to Mathieu Gagné at bourbaki@earthlink.net.

Monod is distributed under the GNU Public License (GPL). See the file COPYING for more information. In brief, this means that contributions to the Monod project must be released back to the community. Write to the maintainer for more information. The best way to do this is to submit them through the SourceForge site. See http://monod.sourceforge.net/projects/. FIXME: Why open source project?

Monod is still at a very early planning stage, so that there are still lots of things to implement! Many of them are described in the present manual — see Future; Results and Future Projects; Compilation and Usage for quick pointers. Also, the TODO file in the main directory contains a brain dump of many features that need to be done. Finally, all interesting ideas are welcome!

Every project has certain attributes and practices that are particularly encouraged. Monod is no different. Here are some of the qualities that are most emphasized for the development of Monod.

• Testing is an important part of the development of Monod. Unit tests are kept in the testing/ directory. It's good practice to add tests as often as possible when new functionality is developed and when bugs are found. The time spent on tests will actually diminish total development time in the long run if debugging, refactoring, etc. are taken into account.

  In addition to unit tests, more comprehensive tests (like the incubcalc example and the singlecelltest executable) help development by providing short-term directional goals.

• Documentation is central to the project, for all the reasons listed in the Orientation section at the beginning. Good documentation has lots of internal redundancies, cross-references, a usable index, a lucid structure, etc. Also, one should never hesitate to add information even when it seems like it's too early. If need be, just prefix with a FIXME: tag.
• Code quality refers to much more than the absence of bugs. It encompasses architecture and a clear large-scale design; good and consistent programming practices; testability, which includes the use of logging directives in the source code (see Logging); etc.