To be blunt, the implementation is incredibly fluid and seems pretty flakey at times. This may be swell if you're able to grab the latest from CVS at a whim, and roll with it when things act up, but it's a bit rough when I've got to go through several layers of admin to get a simple three line edit performed, and am trying to sell this to both students and faculty that are fairly familiar with WebCT and often suspicious of this "new thing".
I certainly don't want to put a damper on the enthusiastic work going on for this nifty module, but I would like to be able to download a stable version and have some reason to believe that it will work as advertised (and that someone actually knows what "as advertised" means and has written it down). We did our initial install of Moodle in late August, and the only thing that ever needed a patch was the Workshop Module (which, BTW, was delivered by Ray with amazing speed and was greatly appreciated). We just did an upgrade to 1.4.3, and everything appears to be working fine except for the Workshop, which has a variety of issues ranging from silly cosmetic problems to potentially significant algorithmic errors.
Can I be bold and suggest two things that might help?
- Use branches in CVS to manage the process in a way that will allow for backpatches to fix older versions? My sense from the discussion and looking at the CVS logs is that work is currently barrelling forth on the main branch and that concrete changes/fixes aren't being committed/managed in a way that would allow them to be applied to older versions. Better use of branches and tags would allow the Workshop module in version 1.4.4 of Moodle to actually be 1.4.3 + plus some basic bug fixes and tested, stable enhancements instead of whatever happens to be in the main development branch when it is released. This would create a meaningful notion of a "stable" version of the Workshop Module, and allow things like bugfixes on the development branch to be patched back onto the stable branch in a controlled way. (I apologize if I'm reading this wrong and there's more process here than I've been able to discern.)
- Come up with some notion of functional and/or unit tests that can be run to help define the desired/correct behavior of the Workshop Module, and to help verify that the "stable" version of it is correct before a release. This module is unusual in that it includes a lot of non-trivial number crunching and very complex interactions. This makes it very difficult to test (as has been pointed out by several developers in this forum). The problem, then, is if you don't use it exactly how the main developers do, you're essentially stepping into uncharted waters, but you don't have any way of knowing that, because there's no documentation of what's tested and what isn't. Note also that there would probably need to be at least slightly different specs for different versions so, for example, you can verify that a patch applied to an old version doesn't break the spec for the behavior of that version.
Unfortunately I just don't currently have time to contribute to the coding side of things in a meaningful way, and am not likely to until this summer
Again, Moodle rocks, and the Workshop Module has enormous potential. I just think it would benefit everyone if a little structure was brought into its development process.
.