Martin Dougiamas

Just as a note to make sure everyone is on the same page: currently the human approval process is only required for the very first time a new plugin is added to the database.   (Anthony Borrow has this job).

I think this is necessary.  It's trivial for anyone to download a plugin, change all the names and re-upload it to the database (for example).  perhaps including some virus or spam, or something more sneaky.  Book+ module, anyone?  Yeah, sounds awesome!

Unlike the old M&P database, subsequent versions of a plugin do not require human approval.  This is to maximise conveneince to developers, so you can release new versions instantly now and make updates any time.  But they are labelled as updates and we have full history on all changes in case problems come up.

Hi Oleg,

Thanks for posting your frustrations.   Many users also have frustrations using old or incorrectly-written (and sometimes very dangerous) plugins too, which is the main problem we are trying to address.

It's by no means perfect yet, but I switched to the new system already because I thought it was important to have something that we could ALL criticise and work on and improve, so thanks for your feedback.  

I want this to be a really high-quality and reliable database that we can base automatic upgrades on later, that's the main reason why we have the validation process.  Modules that do not conform can still be used and published elsewere, but this database needs to have a high standard to avoid problems in the future.  The automatic validation gives this guarantee while also speeding up the initial approval process for new plugins (even so, there are currently 19 plugins with OTHER problems keeping them from being approved).

A few thoughts:

Firstly, the same rules do apply to everyone.  All of the plugins in core have been upgraded quite a lot since 1.9 to make them conform, and this is an ongoing process.  Nothing new gets into core without conforming.  And quite a few of the core developers have also posted their own non-core plugins to the database.

Secondly, yes, our dev documentation sucks.  So much so that we have started an internal project at Moodle Pty Ltd to which will devote all our developers for all of January 2012 to rewriting the entire Developer Docs to make them useful, clear and relevant.  There are three main legs to this: 

1. new overviews and introduction docs,
2. detailed consistent API docs, and
3. an overview/howto for each type of plugin (there will be links to these from each category in moodle.org/plugins)

Thirdly, plugin dependencies were something we added in 2.2, and the Plugins database also supports Sets to link groups of plugins together.  I think it makes sense that developers enter and describe them individually, but something to download a set at once would be a good feature, I think.

Fourthly, we require the code to be uploaded to the database to make sure that we always have the exact bytes that are being rated, evaluated, talked about etc.  It's like apps in an apps store.  Links to auto-zips are just too prone to security problems, regressions and download problems.  It's better for users that you have a defined release process, especially once we have the "Check for updates" feature in Moodle 2.3.

Awesome, Juan!  This is definitely on the right track!

I don't think you're being melodramatic.

I've been worrying a lot about these issues in the wider sense since Hotmail started.  I'm really not a tinfoilhat conspiracy person but it's very clear that Google, Facebook, Apple, Microsoft and Amazon are doing everything they can to amass ever-more-detailed dossiers on their users by combining data from an ever-widening amount of sources.  And have you seen how pushy the Google Toolbar is becoming?

The purposes of all that and the effects on our society can be debated, but we certainly should all be informed that it is happening.   I can recommend the TACO extension for Firefox - try it out and see how much tracking is going on these days.

A field in the Moodle plugins database to indicate that the software contains tracking code is an excellent idea.  I've added MDLSITE-1585 to the list.

Just some really quick thoughts from someone who doesn't know mnet anywhere near as well as I should, there are two main things to think about here:

1) Cross-site authentication.  This seems to be well met by OpenID/OAuth2 etc.  Moodle should be a better part of the wider internet here as both a consumer and a producer.

2) Pulling/pushing data between systems like multiple Moodles or Mahara etc.   To me this sounds like a job for our Moodle 2.x web service infrastructure, and if it needs more security then let's add that or recommend users run everything under https.  We just need to simplify the complex set up we have now.