General developer forum

Like now, bug reports relating to contrib code will go in the CONTRIB project in the Moodle bug tracker. For example: http://tracker.moodle.org/browse/CONTRIB/component/10341.

The new Modules and plugins database will just link to that. (I assume.)

Hi Frank,

Thanks for the feedback, indeed Tim is quite right we will still be using the main tracker and the CONTRIB project to manage bug reports.

I've talked to Martin about this as it would be great to get the new system talking with tracker, and by the sounds of it we should be able to at least pull in the list of issues based upon the component through RSS. We'd need to have a component for every plugin but I don't think that is necessaries a bad thing. Perhaps the one big downside is however that we will be able to only relate to plugins, we won't be able to relate the issues to a version of a plugin.

Cheers
Sam

I think (from discussions with Sam) that your third point is what the 'Set' thing is about. A set might be 'Featured plugins', or it might be a 'Highest rated' set that is populated automatically by Cron.

Hi Howard,

First up thanks for the feedback, regarding the points you raised:

• We will allow users to rate versions of a plugin and it most likely will be in the form of a star rating . The ability to do so will be granted by a capability and likely all authenticated users will have that capability.
• Awards will only be handed out by a very select number of people and is designed to be for things such as the project being constantly maintained and updated, the code being uber secure, etc, they are a bit like badges for the plugin or plugin version. The actual decision about what awards there will be and who can hand them won't be until further down the track.
• The idea behind having only privileged users write reviews is that we will be end up with trustable reviews that will have been created by someone who is known to be an expert in one or more area's of Moodle development and will hopefully be written in a way that honestly reflects the state of the plugin and perhaps even provides constructive feedback for the contributors. Really we are aiming for thorough reviews that look at the plugin both generally and in regards to specific criteria such as how secure the code if, the usability of the plugin, how well it is maintained, and use of Moodle API's.
• Most downloaded, highest rated, yes fantastic point that one. This is what sets are for (the name is pretty ambiguous unfortunately but is the best we could come up with). The idea behind sets is basically to build collections of plugins that share something in common. They will be things that can be calculated such as most downloaded, and highest rated. They will also be things that can't be calculated but are manually created such as must have plugins, plugin of the week, and top plugins of 2011. Hopefully the system will be flexible enough in the end that we can easily create new sets as we think them up.


I hope that answers some of the questions you have, and again thank you for the feedback!

Cheers
Sam

I agree that the connection between the proposed plugin and the tracker should be as painless and transparent as possible.

Perhaps the tracker could provide at least an RSS feed to the plugin to see which bugs have already been reported? And in case there's a new bug a button as suggested by Mark would indeed be great.

Agree with Mark. The vast majority of users look at CONTRIB and throw their hands in the air. Coupled with Sam's suggestion for basic instructions w/each plug-in, and the Amazon-like review/star system, this replacement would be a much more powerful tool.

Hi Mark

Thanks for the ideas. Looks like the integration with tracker is a pretty popular topic. The plan presently is to still use the CONTRIB project in the main tracker, and will of course still require people to have an account and log in to create the bug.
I had talked to Martin about this and we decided this was still the way we want bug tracking to occur, however I can certainly see what you are getting at with the points you've made.
First up I really like the idea of having a report bug button, I certainly think we can do this an will make a note of it.
Second in regards to the mini forums on each plugin, I had thought about that a little, however after discussing it with a few people we decided we would use the comments API within Moodle allow authenticated users to post comments. The plan is then to tie that in with the notification improvements within this new system so that when someone posts a comment on a plugin, or plugin version you get a message through the messaging system. Hopefully to further this we will allow users to choose to recieve notifications about any plugin, not just plugins they are a contributor for.
I know that this isn't overly different to the present system however hopefully the notifications will at least keep you up to date what what is going on. I also plan to redesign the comments html for this plugin so that it more prominent and friendlier looking feature.

Does this sound like it would meet your needs or do you think we would still be better to integrate discussions or a mini tracker?

Cheers
Sam

I agree - communication with users is tricky at the moment.

The most difficult thing for me (as Mark mentions) is that there isn't an RSS feed/email generated when people add comments to plug-ins at the moment, so if they ask questions I have to remember to go and look every now and then.

I like the idea of connection to forum/tracker etc.  I don't really care where you think the best place for communication takes place, as long as its consistent, public and it notifies me as the maintainer automatically.

Hi Ramon,

Thanks for taking the time to read the proposal and providing feedback.
In regards to approvals there is going to be two ways for a plugin, or version to get approved.
The first is as it currently happens a small number of people who are trusted to approve plugins will head in and mark things approved. Currently this is people like Helen, Anthony, and Michael Blake.
The second method is that users can be given a special capability after which any plugins or versions they create will be automatically approved.
I have no idea who is going to be on this trusted list or who decides, but it will be possible. I suppose the list will be made up of well known, trusted people.

In regards to providing CVS information it is completely optional. Under the current proposal you will be required to upload a file, and optionally you can choose to enter the information about your public versioning system. I haven't replied to Sam Marshall's post yet, he raises some good points + ideas that will likely see the it being changed to 'you either upload a file or provide information about your vcs and a download link'.

As for registering sites there are plans, in the future, probably distant future, to provide a means of installing + updating plugins from your Moodle installation. This will require that plugins + the version being used are tracked and essentially registered although I don't think there are plans to collect and correlate that information from an installation. It would be something that people would have to explicitly turn on.

Finally in regards to the tag cloud, the plan is presently to enable tagging of plugins, however we will still require a plugin to be created in a single category. The category will describe the type of plugin, not what it does. So 1 category, 0..n tags.
As for displaying the tag cloud, I'm sure it will be on the front page of the new system somewhere

Cheers
Sam

I'd also like to avoid having to manually zip and upload a new version of my plugins, every time I make a change to them. The current system of being able to submit changes to CVS and have them automatically appear for download the next day is much easier.

On a related note, I don't suppose there is any chance of getting a moodle.org hosted git CONTRIB area set up, with automatic linking from tracker? Since Moodle core moved over to git, CONTRIB commits via CVS no longer show up in tracker (and third-party hosting, such as github, wouldn't allow that linking to take place either).

There's much in Sam's comment that I love.

My thoughts:

Encouraging contributions

The move to Git is a fantastic one for helping new developers fork, tweak or patch, and contribute the changes. Many plugins in the current database either have no public repository or no obvious way of accepting patches. Anything we can do to encourage public repositories and easy contributions gets my vote.

Flexibility

Lots of teams will use different systems. I think it's great if we have a simple way of pointing out where the source is, how to get a zip download, where discussion is located, etc. IMO the way the Ruby community does it at Rubygems.org is a winner (e.g. http://rubygems.org/gems/rspec). Most people use github, but you could use any option you like - since github automatically produces downloadable packages, we could just point to the latest one without any need to trigger a special process.

Credibility: stats and voting

I think it'd be great if we had the ability to see downloads (of limited use when many will use Git) and also to submit a quick 'user's 5-star ranking' and a rubric-based assessment about overall quality. The 5-star ranking would tell you whether people love using the module, the larger assessment would help institutions identify whether a module is community-rated as being suitable for installation.

Having a rubric with visible, community-managed criteria (security, performance, etc) would be great. I'd imagine reviews being conducted by Moodle Partners, HQ developers, freelance developers etc.

None of the assessments would be anonymous, and would be explicitly done against a specific version number.

That's probably more than 2c worth ;)

Myles C.

Great work Sam H! - I agree with Sam M - having to upload a "package" file each time you update your git repo seems to break some of the big advantages of people using their own repos - it's much more convenient to be able to link to a download from github (or elsewhere) - it's unlikely I'd remember to "update" the m&p entry each time I make a push into my git repo - and I don't think I should have to. If Moodle still needs to keep a "package" file seperate from the externally hosted repo IMO it should do this in an automated fashion.

To handle versions of interally stored packages - for blocks/modules the script could check the version.php file to see if it has changed since it last looked and if so it could grab the code down again and store the package.

Patches/packages could also use a similar method - using a version.txt or version.php file to signify versions?

..Really looking forward to the ability for full reviews to be added to plugins!

Hi Sam,

Intersting stuff.
By all means the idea of making creation of new versions as quick, painless, and automatable as possible is certainly an idea worth investigating and one that I would love to find a good solution for.
The current system, you make changes in CVS, the new download pages are produced on a regular basis, and everyone gets the latest version.
With the new system where we are tracking versions properly having a record of each version is important. Reviews, awards, sets etc will all make use of particular versions. It is pretty crucial to providing information that can be trusted and readily availble.
That all said really it only means we need a record for each version in the database.
Presently the proposal requires that you manually create a new version through the system and that you upload a zip of the version.
I completely agree that it could be made quicker and I'd love to do so. Looking through your ideas for how this could be done:

a) Looking up a standard link: strangely enough this could work. Part of getting the zip is that we will extract it and look at version.php so we could probably peice together enough of a version record to get it into the database.

b) The descriptive XML file: This is certainly doable, it would need to contain a link to the file we could curl down, and could optionally contain the other information you can specify for the version such a relese notes and whatever.

c) The webservice: At one point or another I did actually discuss using webservices like this with Martin however we decided against it. This option is a no go.

d) Throw away versioning: This one is definatly out, in order to provide trusted information and access to old versions we need to have the version stored ourselves.

From the options a or b sound good to me, and if I had to choose one I think I would go for option b, but perhaps we can support both? I don't know. I'll see if I can steal some of Martin's time and see what he thinks.

Regarding the Install this plugin button that sounds like a cool idea, and easy enough to implement. I'll make a note of it and see about getting it in.

btw. Thanks for reading over the proposal and giving feedback

Cheers
Sam

Disagree - doing this means that Moodles webroot would need to be writeable by default - in my opinion this is something we should discourage as much as possible - The security risks this could cause far outweigh the convenience.

+1 for a one click install option.

I agree about all the security issues, but given Wordpress's failure to cause global server meltdown, an option for advanced users to do it can't be that bad, especially given Martin's point about encouraging timely upgrades.

I see no problem adding extra authentication just for that operation as others have mentioned, and the hassle of using FTP, or chmod or whatever would be more than worth it given the time saving, especially when managing lots of sites.

Maybe I'm being a purist but I think that any serious/seasoned developer would already be using a SCM/VCS of some description. It's a basic necessity of the job and it's not hard to learn. Places like github make it very easy to manage projects and have some great instructions and tutorials.

That is not to say that someone who isn't at that level can't contribute code, but I think there are already avenues for doing that - eg posting to a forum, tracker etc.

Regarding tainted code in the linked versions, two thoughts:
1. Reviewers would soon find out and perhaps they just blacklist that user/plugin - maybe a policy should be agreed to before an new entry is added to the database?
2.  I'm sure it would be possible to automate a check that the link does in fact download some pluggable code;

Shane.

great work Sam - looks really promising! - flick me an e-mail if you make it to chch and want to come over for lunch/dinner/coffee with your new Wife! - hope the wedding plans go well!

Hi Sam,

thank you for your work and for the interesting screenshot, and of course our best wishes for your marriage . I tried to gather as many information about this thread, however i still have some doubt (apologize if I 'm missing something already discussed):

• writable wwwroot: as Dan pointed out, it is a concern we should take care of
• as far as I can understand it is a web interface. I'm a little concerned about the fact an Admin can download and install plugins at will, easily making a system out of control
• Moodle 2.0 has a cli upgrade script very useful to automate upgrade processes of sites using a local git/cvs common repository.  Would the plugin still have a git/cvs repo where the plugin can be downloaded at their proper version ?

Many  thanks,
Andrea

Juan - Development:Modules_and_plugins_replacement_proposal gives the direction that things are taking and it remains a work in progress (on hold until Sam gets back) but as mentioned you can check the current status of things at MDLSITE-571 or if you are interested in what is happening with the code you can checkout https://github.com/moodlehq/moodle-local_contrib. I look forward to seeing things come together over the next several months. Your comments in the tracker or on the Moodle Docs page would be very helpful. Peace - Anthony