Plugins traffic

Approaching improvements in the plugins directory

 
 
Picture of David Mudrák
Approaching improvements in the plugins directory
Group DevelopersGroup Documentation writersGroup Moodle HQGroup Particularly helpful MoodlersGroup Translators

Couple of improvements in the Plugins directory and associated procedures are just being planned and it's the right time to discuss them now.

It's evident we need to improve the approval procedures for the new plugins. The queue of submitted plugins awaiting for the initial review became pretty long (45 plugins right now) and it's current top priority for the plugins facilitators team to deal with it. We believe it would help if more validation checks are executed automatically. Reported issues can then be fixed by the plugins authors promptly. It's not rare that the acceptance review takes longer just because the newly registered plugin does not have the basic meta-information filled (description, documentation links, source code management URL etc). We currently work on some UI improvements so that maintainers are warned and asked to fix these formal aspects of the registration prior to actual human review of the plugin code.

There is a plan to implement these validators (that include checks for the coding style, strings files syntax required by AMOS, code plagiarism etc) so that they can be executed separately from the plugin registration. In other words, the plugin author should have a chance to execute all these checks even before they actually submit their plugin to the directory.

We would also like to give the developers community a chance to participate on plugins reviews and testing. In some sort of peer-assessment spirit. Peer-reviews are generally very good for learning and reflection (developers seem to spot mistakes in other's work more easily than in their own work). We all learn well by looking at other's work and comparing it with our own. And it would provide the authors with richer feedback if their plugin was checked by multiple peers.

Some sort of integration with crowd-funding and Moodle jobs offering databases would be nice to have. It might help the plugins authors to collect funding for their work.

We also plan improvements in the UI for maintainers of existing plugins. One of the first things I would like to see soon is a mechanism that allows to easily release a new version of the plugin after it has been tagged in the external source code management system like Github. The directory already supports it partially, thanks to the cool repository plugin by Dan Poltawski (in the file picker, you can fetch the ZIP directly from Github without the need to download and upload it). We plan to extend this further so that releasing a new version in our directory is just a matter of a button click (or two).

 
Average of ratings:Useful (1)
Picture of Blair F.
Re: Approaching improvements in the plugins directory
 

This is great news.  I would also love to see mandatory Release Notes for each version upgrade.  I'd like to be able to decide if an update to a plugin is worthwhile and know what changes to expect as a result of the update.

 
Average of ratings: -
Picture of Marcus Green
Re: Approaching improvements in the plugins directory
Group Particularly helpful Moodlers

+1 for Blairs comment. It would also nice if people who download plugins had a chance to come back later on and click something that said, I have tried this plugin and I am now using it in production. Download statistics are nice but you never really know if it is being used. 

Also for developers it would be good to be specific about the code rules. I have a plugin in the approval queue (BTEC) that throws a code checker issue because it needs a function call in a style that is outside the style rules but I cannot work out any other way of doing it. 

Welcome to the job David, it is the plugins that make things exciting with Moodle.

 
Average of ratings:Useful (1)
Picture of Marcus Green
Re: Approaching improvements in the plugins directory
Group Particularly helpful Moodlers

I meant to say that the call is to core Moodle code so that is why I cannot change the syntax (or at least don't know any other syntax for it)

 
Average of ratings: -
Picture of David Mudrák
Re: Approaching improvements in the plugins directory
Group DevelopersGroup Documentation writersGroup Moodle HQGroup Particularly helpful MoodlersGroup Translators
I am not sure if simply setting the release notes field as mandatory would automatically mean that folks put useful information there. But we will consider this suggestion and eventually integrate it into upcoming automated checker tools.

WRT the coding style rules, please note we do not generally discriminate just because of it. The main point is to make the code easier to read for other Moodle developers. This generally helps with maintenance, bug fixing, code peer-review and sharing.

I'm sorry for the delay with the review Marcus.
 
Average of ratings: -
Picture of Joseph Rézeau
Re: Approaching improvements in the plugins directory
Group DevelopersGroup Particularly helpful MoodlersGroup TestersGroup Translators

David "I am not sure if simply setting the release notes field as mandatory would automatically mean that folks put useful information there."

Very true but... who reads the release notes anyway? I tend to consider my own release notes more as "notes to self" than "notes to the world".wink

Joseph

 
Average of ratings: -
C'est moi :-)
Re: Approaching improvements in the plugins directory
Group Documentation writersGroup Particularly helpful MoodlersGroup TestersGroup Translators

IF release notes contain useful information, i'm very interested to read them.

I can then decide if i really want to make the update, if it correct bugs i encouter or provide new feature i need. Or better wait to update if i consider it risky...

 
Average of ratings: -
Picture of Joseph Rézeau
Re: Approaching improvements in the plugins directory
Group DevelopersGroup Particularly helpful MoodlersGroup TestersGroup Translators

Thanks, Séverin. Now when I write/update the release notes of my own plugins I will remember that there is at least one person who will read them - besides myself.approve

See you soon in Paris,

Joseph

 
Average of ratings: -
Picture of David Mudrák
Re: Approaching improvements in the plugins directory
Group DevelopersGroup Documentation writersGroup Moodle HQGroup Particularly helpful MoodlersGroup Translators
I like release notes and I think they are important for end users. I am pretty sure they read them. It is a perfect place to highlight new features, summarize list of fixed bugs etc. Even if it is just a single line (as we aim to support "release soon, release often" style). The 'git shortlog' command can be useful when preparing them.

I must admit I never really liked much that the plugins directory automatically copies the README file contents into the release notes field for the newly uploaded version. I just think that this file has different purpose. Some open source projects used to have a file called CHANGES that would be more appropriate here. I am wondering what other people think about this feature actually.
 
Average of ratings: -
Tim at Lone Pine Koala Sanctuary
Re: Approaching improvements in the plugins directory
Group DevelopersGroup Documentation writersGroup Particularly helpful Moodlers

Could we have a convention ...

Well, at the OU we have a convention that we try to put an internaldoc folder in each add-on, where we put things like test scripts. (I don't know why we don't call the folder doc).

We coud have a convention like files called releasenotes.v1.2.txt in there, where v1.2 matches the git tag, and the plugins DB could copy that into the release notes field.

Hmm. Seems a bit too complicated for people to discover, even though it is about as simple as it can be.

 
Average of ratings: -
Davo
Re: Approaching improvements in the plugins directory
Group DevelopersGroup Particularly helpful Moodlers

In most cases, a CHANGES file, that listed all the changes from all releases (most recent at the top) would probably be more helpful (especially if the site is a few versions out of date and wants to read a range of changes).

Plus, your proposal would require the use of git tags, something which many (most?) plugins don't currently use (even accounting for any plugins that use a different version control system anyway).

 
Average of ratings: -
Picture of David Mudrák
Re: Approaching improvements in the plugins directory
Group DevelopersGroup Documentation writersGroup Moodle HQGroup Particularly helpful MoodlersGroup Translators

a CHANGES file, that listed all the changes from all releases (most recent at the top)

I tried this. It's a hell to maintain on multiple branches. The compromise that fit my style most was that CHANGES would contain recent changes for the current branch only.

Separate release notes files is a robust solution from technical point of view. But I would personally not like that many small files in the root folder of my plugin.

Mediawiki, for example, has a file like RELEASE-NOTES-1.21 on each branch (REL1_21 in this case). They have release notes for the given (1.21.x) branch only, not previous. And then, this file is being updated during each release (git tag) with new notes added to the top of the file (such as sections for 1.21.0, 1.21.1, 1.21.2 etc).

 
Average of ratings: -
Picture of Marcus Green
Re: Approaching improvements in the plugins directory
Group Particularly helpful Moodlers

"We coud have a convention like files called releasenotes.v1.2.txt in there, where v1.2 matches the git tag, and the plugins DB could copy that into the release notes field."

I like release notes, I put some generic information in readme.txt (e.g. unzip it to a folder called /moodle/mod/bla)

And then some version specific notes in version files e.g.

releasenotes12.txt releasenotes13.txt




 
Average of ratings: -
Picture of Danny Wahl
Re: Approaching improvements in the plugins directory
Group DevelopersGroup Particularly helpful Moodlers

There is a plan to implement these validators (that include checks for the coding style, strings files syntax required by AMOS, code plagiarism etc) so that they can be executed separately from the plugin registration.

I'll admit that one raised my eyebrow.  I wonder if you could elaborate on "why?" and "how?"?

 
Average of ratings: -
Picture of David Mudrák
Re: Approaching improvements in the plugins directory
Group DevelopersGroup Documentation writersGroup Moodle HQGroup Particularly helpful MoodlersGroup Translators

Yeah. I admit it surprised me as well when I first heard this. But apparently, there are people round there who do such things - they simply try to repackage someone else's repository and upload it to the Plugins directory as their own plugin :-s

Indeed, in open-source world, free code sharing is natural thing. Also making a fork of someone's project may be a benefit for the community (although we generally prefer collaboration over forking). Anyway, as long as there are known attempts of clear plagiarism, we want to address them. The exact details are not known yet and I am aware this might be tricky to implement properly without too many false positives detected.

 
Average of ratings: -
Picture of Joseph Rézeau
Re: Approaching improvements in the plugins directory
Group DevelopersGroup Particularly helpful MoodlersGroup TestersGroup Translators

Plagiarism detection is like detective work, an interesting, sometimes exciting, often boring but always difficult occupation.

Joseph

 
Average of ratings:Useful (1)
Tim at Lone Pine Koala Sanctuary
Re: Approaching improvements in the plugins directory
Group DevelopersGroup Documentation writersGroup Particularly helpful Moodlers

Heading off-topic, but if you find it difficult to find the unread posts in this forum, you might like to vote for MDL-45841.

 
Average of ratings: -
C'est moi :-)
Re: It is hard to find unread posts in blog-style forums in the plugins directory
Group Documentation writersGroup Particularly helpful MoodlersGroup TestersGroup Translators

Thanks Tim for this tracker issue, voted for it!

 
Average of ratings: -
Picture of Joseph Rézeau
Re: Approaching improvements in the plugins directory
Group DevelopersGroup Particularly helpful MoodlersGroup TestersGroup Translators

@Tim,

This forum seems to work in a different way from all the other forums on moodle.org, and I don't understand why.

Joseph

 
Average of ratings: -
Mary Cooch
Re: Approaching improvements in the plugins directory
Group Documentation writersGroup Moodle Course Creator Certificate holdersGroup Moodle HQGroup Particularly helpful MoodlersGroup TestersGroup Translators
Joseph: I believe it is because this forum is in the blog-like format.
 
Average of ratings: -
Picture of Nicolas Martignoni
Re: Approaching improvements in the plugins directory
Group DevelopersGroup Documentation writersGroup Particularly helpful MoodlersGroup TestersGroup Translators

Agreed. This forum blog-format is not very friendly to use. I voted too for MDL-45841.

 
Average of ratings:Useful (1)