Wiki

The way we solve potential conflicts is to keep our own copy of the code - let's call it OU Moodle - separate from the official Moodle code.

We can do whatever we like with OU Moodle. We can only do things in official Moodle that the community agree with.

Now, it is much easier for us if OU Moodle and official Moodle are as similar as possible. The main reason is so that when there is a new Moodle release, it is easy for us to combine those changes into OU Moodle.

And it is good for the community if, when the OU have done something generally useful, that goes into core Moodle.

So really, not much conflict, but quite a lot of pain for us every 3-6 months doing code merges, followed by testing and bug-fixing.

However, it is not as painful as it might be, because of Moodle's architecture. I lot of things can be done as plugins (ouwiki, resourcepage, studycal course format, workflow block, many admin reports, ...) without changing the Moodle core.

Yes, there are sometimes technical arguments about how things should be done in official Moodle, or whether or not they should be done at all. But my experience is that the Moodle community is a great place to have these debates, because there are a lot of knowledgeable people here, the arguments tend to focus on the issues, and everyone had a common goal of making Moodle as good as possible. Sometimes, the decision is not what is most convenient for the OU, but there is normally a sound reason, so you accept it, and often, during the debate, you learn something.

Thanks for acknowledging the OU's contribution. Unfortunately our special funding for the transition to Moodle runs out soon (we will still be maintaining things, of course, and developing new stuff but at a slower pace) but there are still a couple more things which are coming up that will be released into contrib for others to use: the 'vote' module (a full-featured replacement for Choice, with lots more 'question types' and the ability to allow tutors to create polls just for their tutor group, etc), which is being tested now, and the 'oublog' module (a replacement for the blog feature that provides a different way to organise individual and course-specific blogs), which is currently being developed. Both of these were initially designed by me but the development was outsourced. Then there's what I personally am working on now (or should be!) which is a new 'shared activities' system that lets any student create their own activity from specific types (such as forum, ouwiki) and invite people from anywhere on the system to join in. If any of these sound interesting, keep an eye on the general developer forum as I will post once those are available. (Hopefully in April/May.)

As for if we were to be maintainers for an ouwiki module included in core (which seems unlikely, but hey):

There's no problem if a suggested feature that somebody else wants to develop is a good feature, coded well, and makes sense from a user interface point of view. If the OU actively wants to not have a feature even though it's a good feature, then we could request that it includes a sitewide configuration flag or something. (Presumably we would have a good reason for not wanting it - so it might be an option that other institutions would also welcome.)

Where there'd be a problem is if the contributor thinks something is a good idea, but we think it's a crap idea (not just that the OU doesn't want it). Or if something's been developed but the code is poor. However that would always be an issue... Hopefully it could be minimised by encouraging people to contact the maintainer (me, likely, to begin with anyhow) to discuss any plans before development so that we could agree a way for them to implement the change that would fit well into the module. Obviously in the final case Martin D can make decisions as to what goes into Moodle and what doesn't.

As noted, I think the above is looking rather hypothetical.

--sam