Dokeos community release
From Dokeos
The Dokeos community releases are made using an open, community driven development process. Everything in this community release process is as open as possible: everything is discussed on forums, timetables are first proposed to the community, and we try to follow free software / open source development practices that have proven succesful in other projects.
The community release process is an attempt to improve both quality and speed of Dokeos development. The first stable community release, 2.0, was released on February 8th, 2006. Since then we've had four bugfix releases (2.0.1 through 2.0.4), and the second beta version of community release 2.1 has just been released. This would put us in a six-month schedule for major releases, which is a very well-liked schedule for open source software, amongst others the popular Ubuntu and Fedora Linux distributions, the GNOME desktop environment, OpenOffice...
Contents |
How to participate
If you feel like participating in Dokeos development, it has never been so easy! Just post a notice or question on the Dokeos forum and we will help you get started. We can always use documentation writers, translators, testers, and programmers. You can also help develop extensions and plugins for Dokeos.
- For developers, reading the Dokeos programming tutorial won't hurt
- Translators can use the online Dokeos Language Translation Tool (DLTT) or the local version, the myDLTT extension.
- We maintain our code version history on the CVS service provided by SourceForge
- Discussions and decisions are done publicly on the forum
- Dev Wiki : community driven website for documentation
Solid release process
We rigorously follow the release early release often principle. Community releases are made for the users, and we want all users to be able to test the software an provide feedback as soon as possible.
Releases are categorized as major "feature" releases, and smaller "bugfix" releases. The major releases follow a time-based schedule: we release on time (excepting acts of god ;-), cutting features that are not stable enough yet. Smaller bugfix releases are made soon, e.g. a few weeks after the initial release. When security leaks are discovered we try to have a patched version within 24 hours.
Aim at stability
We aim at stability by
- releasing early, so people can test changes in the software, offer feedback, suggestions, and file bug reports as soon as possible
- continously refining the software, improving code where needed, and making very frequent bugfix and testing releases. There's no use in fixing a bug and then letting users wait for months until they can benefit from it
- adding features even when they are not perfect, simple new additions are fine as long as they work.
- having a fixed release date, by which features should be relatively stable. This creates a mindset where developers aim at constant stability. Features that don't make it on time are rescheduled for the next release.
- most of the time releases don't feature a lot of big changes at once. There are more releases, but less big changes per release.
Relation to the rest of Dokeos
The Dokeos community releases are not competing with the classic Dokeos but bringing new ideas to it. To avoid confusing Dokeos company releases with Dokeos community releases, the community releases will be numbered CR2.0, CR2.1, etc, whereas Dokeos company releases will be numbered Dokeos 1.8.0, 1.8.1, etc.
Focus on the future
We intend to develop the core of the Dokeos software, to aim at perfecting the architecture underneath. It's not as sexy as new features, but a solid Dokeos core gives us a better chance at producing great software which can add features with as few bugs as possible in an acceptable timeframe.
In fact there is already an experimental Dokeos LCMS development underway, which will produce just such a solid architecture, finally giving Dokeos a good way of dealing with all sorts of learning objects and their storage in a generic way. If this experiment works out, the intention is to let the community releases grow towards this architecture. E.g. you would be able to upgrade existing community releases 2.0, 2.1 … to the new Dokeos LCMS software.
We will keep releasing Dokeos once a year under strict quality control but the community release will live its own life, full of experiments, new features and new developers. The classic Dokeos release will recycle what is useful for the vast majority of users (i.e. no guarantee that Dokeos CR features will appear later in Dokeos release although they might be released as Dokeos Extensions).
How will the community release help increase quality?
The idea of having a community area with minimal collaboration rules suggests, at first sight, the idea of chaos. Open source development recent history, as well as Wikipedia content community process, proves on the contrary that this can benefit the quality process.
On the other hand, the classic Dokeos releases remain supervised and validated by the Dokeos company and its affiliated partners only, so as to guarantee stability, simplicity and reliability. This re-organization of our workforces will even be an opportunity to tighten the quality rules management and provide the user community with software that outbeats current commercial packages.
See also
- Dokeos releases - a general overview with a handy timeline
- Dokeos community 2.1 release_notes
- Dokeos community 2.0 release_notes
