Plugin contribution

This page describes how to contribute your code into the Plugins directory to share it with the Moodle community.

Why

You are encouraged to share your plugin with the community. But firstly, to be clear and honest, you do not necessarily need to submit your plugin into the Plugins directory. Maybe it is a custom plugin that solves one particular site's needs and you do not really want to share it with others. Remember you can always simply host your plugin on your own site and let users download it manually from there.

Having your plugin registered with the Plugins directory has several benefits.

Your plugin is easier to install. Plugins directory integrates with Moodle. Administrators can simply install your plugin from the plugins directory via the web interface.
Your plugin is easier to update. Whenever you release a new version of your plugin, all administrators having it installed are notified about the available update. They can easily upgrade to the new version from within the Moodle administration UI.
You reserve the component name (frankenstyle) of your plugin. Plugins directory is the official register of Moodle plugins. As with the internet domain names, there can't be two plugins having the same component name.
The plugin can be localised. Plugins in the Plugins directory are implicitly registered with AMOS and can be localised using the same tools that are used for localising the standard Moodle UI.
The plugin must be approved. Many institutions respect the approval review procedure and do not allow to install a plugin on their servers unless it has been approved in the plugins directory.

Before you start

Before submitting your work to the Plugins directory, you should make sure you have all required and recommended resources available.

Repository - In most cases, you are supposed to have the plugin code published and shared in a way that facilitates collaboration on further development. Ideally, you have the code available in a public Git repository. Most developers found Github a good place to host their code on. The Plugin repository page provides more details.
Tracker - You are expected to have a system where users can report issues, bugs and feature requests for the plugin. Again, many developers use Github issues happily these days. You can also use the Moodle tracker if you prefer. See Plugin tracker for more details.
Documentation - The plugin should have a good documentation available. See Plugin documentation for options.
Screenshots - Prepare good screenshots that illustrate your plugin's essential features.

Overview

Shortly, the workflow of publishing and maintaining your plugin in the Plugins directory looks like this:

Workflow of contributing a plugin into the Moodle plugins directory (SVG version)

You upload the initial plugin version for approval. To help the approval review go smoothly, please feel encouraged to review the Plugin contribution checklist and follow all the guidelines there.
After you submit the plugin for approval, it is best to count with a week or two before you get initial review results. We generally try and provide the feedback sooner, but it is not always possible. The actual approval queue stats are available.
Almost all plugins are sent back as "needing more work" as a result of the initial review, and there is no reason to feel bad about that. It is natural part of the workflow. You may find particular issues reported into your tracker so you have an opportunity to demonstrate your ability to co-operate with the reporter to resolve them.
Once the plugin is approved, its strings are registered with AMOS and can be translated. The plugin itself should ship with English strings only.
We do not automatically pull from Github. You have to implicitly release new version via the Plugins directory. Still you are encouraged to use Git tags - releasing new version is easier then.

The Plugin Frequently Asked Question (FAQ)

Question: I have written a new plugin to share with the Moodle community. What is the process for contributing the code?

Answer: First, thank you for your generosity and desire to share your work with the rest of the Moodle community. Code contributions are highly valued and Moodle wants to encourage creativity and generosity in keeping with Moodle's social constructionist pedagogy.

As mentioned, there are various tools to help you share and support your contribution. By using a consistent methodology, your Moodle related code will be more easily found, tested, used, maintained, documented, and evaluated by fellow Moodlers and developers. Learning to use the various tools common among Moodle developers will help you to efficiently and effectively develop, share and maintain your plugin.

How to submit code

See Plugin contribution checklist.

You have created some code that you would like to contribute to the Moodle community. The first step is to choose which Git code hosting site you want to use. Both github.com and gitorious.org are popular. Follow the instructions for creating a public repository for your code. This will allow others to download your code as well as suggest possible patches. As you become more familiar with collaborating with others you can also control who else you want to be able to push changes into your repository (i.e. write access).

In order to facilitate a common naming convention of Moodle related repositories, it is suggested that you use the following format: moodle-{plugintype}_{pluginname}. For example, the birthday block has a repository name of moodle-block_birthday and is located at https://github.com/arborrow/moodle-block_birthday. Other developers can fork the code and work from their repositories.

How to request that your code be tested/reviewed

If you do not already have an account on the Moodle Tracker, create one and login.
Create a new "Task" issue in the "Non-core contributed modules" project, selecting 'Add a project here' as component. Your issue will be a request that the code be tested and reviewed.
Provide the link to the repository (i.e. https://github.com/arborrow/moodle-block_birthday)
Provide a clear description of what the code does and the functionality that it adds to Moodle.
Provide any other links to supporting documentation

The Contrib Coordinator will then work directly with the code contributor via the Tracker to help evaluate the code, work on resolving any questions/issues found, etc.

Contributors are encouraged to follow Moodle's coding guidelines Coding.

Contributors are encouraged to maintain a branch for each major Moodle release (i.e. 2.3, 2.4 etc.). The HEAD branch should be used as the development branch.

Contributors are encouraged to associate each change made to an issue in the tracker. This practice is done by Moodle core developers and it is a good habit to get into so that you can go back and see why various changes were made to the code. Simple practices like these help to create good documentation of the code as it develops and matures. Commits should begin with the Moodle tracker issue number followed by a brief description of the change.

How to provide documentation

Having great code available to the community is wonderful. It is also important to educate users about how to use the code with documentation in Moodle Docs. See Plugin documentation for details.

Share code in the Moodle plugins directory

Now you have a place for users to get your code, how will they know it exists? Please register your plugin in the Moodle plugins directory.

Users may leave comments on your entry, so please check it periodically for questions and bug reports. If you include contact information or a link to a discussion, your users may be able to contact you more directly.

Keep in mind that plugins added to the Moodle plugins directory have to pass both an automatic and a manual validation process before they will be visible to other Moodle users.

If you are using git to store your code, you will need to export the repository cleanly into a zip file containing one folder, named after your plugin. Use this code to do that:

 git archive -o path/to/filename.zip --prefix=yourpluginname/ yourbranchname

Support code and get feedback with forums

As users become familiar with the plugin, discussions about the code are likely to emerge. We strongly urge you to place links to at least one forum at moodle.org in your plugins directory entry as well as in Moodle Docs.

It is important to respond to users who have questions about how to use the code, suggestions for how to make it better, etc. If a plugin maintainer thinks there is sufficient need for their plugin to have its own forum, they should create a Moodle Community Sites issue for it in the tracker.

General plugins forum is a generic forum. Be sure to put the plugin name in the discussion title.
Moodle in English
Full list of courses on moodle.org

Maintain and refine code using the Tracker

In order to facilitate keeping track of feature requests, bugs, and other code issues, the contributor may request that a component be created in the CONTRIB section of the Moodle tracker.

The contributor can be added to the group of CONTRIB developers in the tracker to manage the issues assigned to them and better coordinate with other developers. Plugin users can then add issues which can be assigned directly to the maintainer. The tracker helps to manage the work flow involved in fixing bugs, working through feature requests, and maintaining the code. When committing changes, maintainers are strongly encouraged to begin the commit comment with a tracker number.

We strongly encourage users to involve themselves in the process of creating a useful issue in tracker. For the developer and code contributor, describing the fix can help clarify the need for the code change. Further, it helps to establish good documentation about how the code developed. Others will be able to identify the issues addressed and understand why a particular decision was made.

Summary

It is hoped that following this procedure, will help guide contributors of code in the process of learning the tools and skills used by the Moodle developers. Learning to submit code by using the tracker, work the code with Git, support the code by providing documentation, share code in the plugins directory, maintain the code by using the tracker, and evolve the code by using the Moodle.org forums will assist you in successfully contributing to the Moodle community and working with Moodle's developers.

Throughout this process, the CONTRIB Coordinator is here to encourage and support those contributing code to the Moodle community and fostering the development of tomorrow's Moodle developers.

Eventually, the community may wish for the code to become part of the Moodle core. By following the steps above, the developers will be able to evaluate the merit of the plugin, understand how users have used the code, see the issues that have emerged and thus have more information to make an informed decision about whether or not to incorporate the plugin into the standard distribution.

Documentation