The Moodle Developer Resources is the official source for all Moodle documentation. It's here to make your life as a Moodle Developer easier. To serve that purpose it has to be up-to-date, and as accurate and complete as possible. Every contribution is important in achieving that goal and we hope that you are able to be a part of that mission.
If you are new to Open Source contributions, or you are interested in learning how to run or contribute to an open source project, then these resources from the Open Source Guides website may give you some help and insight into common practices. It has a collection of resources for individuals, communities, and companies who are interested in open source contributions. The following guides may be especially useful to you:
Code of Conduct
Anyone can get involved with, and add to, these resources - you don't have to be a developer or documentation aficionado. Here are a few ideas to get started:
- Look at our list of good first issues
- Migrate a document from the legacy docs
- Fix typos and grammatical errors
- Document new Moodle features
- Mark a deprecated feature as deprecated
- Raise issues in GitHub for features which need to be documented
- Triage existing issues
If you need help, please reach out to us and we will do our best to advise you.
If you're eager to jump in, then the fastest way to set up your development environment is to have NVM installed and then run:
npm i -g yarn
Migrating legacy docs
We are currently migrating documentation from our legacy documentation site, and one of the best ways to contribute with documentation is to help with this migration process.
We have created a number of tools to make this a little easier and to automate as much as possible. These are mostly focused around our migration assistant. You can find its full documentation by running:
yarn migrate --help
What we automate
The migration assistant will:
- try to guess the:
- page title
- relevant tags
- create the directory structure to the new markdown file
- fetch any images included in the original page
- WikiText tables to either Markdown tables, or HTML tables as appropriate
- page headings
- common font formatting like bold, and italics
- code blocks
- some common
*Note*syntaxes to use an Admonition
- InterWiki links to fully-qualified links
- Regular links to markdown links
- run markdownlint in fix mode to automatically fix any common, fixable issues
- update the links for any internal documentation which has already been migrated
- add the migrated page to our list of migrated pages
- update any links to the migrated page
Using the assistant
In most circumstances you should not need to pass any special options, and you will just need to pass the name of the document you are migrating, and the path to the location you'd like to migrate it to, for example:
yarn migrate [Name or URL of legacy document] [/path/to/new/document]
You can either pass the full URL to the legacy document on the legacy devdocs site, or the name of the legacy document is the name within the URL, for example, in the following URL:
The page name is
When choosing a location to migrate the document to, first ask whether the page contains information which relates to a particular version of Moodle - this may be a guide for a subsystem, or plugintype for example. If so, then this must go into the
docs folder. Most other content should go into the
The structure of the documentation describes these two locations in further detail.
yarn migrate Moodle_and_PHP ./general/development/policies/php.md
The migration assistant is not perfect and is not aware of all WikiText features. Additionally if the formatting is not correct in the WikiText, some aspects may become incorrectly formatted during the conversion.
After performing a migration it is important to review the page content. You should attempt to:
- update any relevant styling
- remove legacy content which is no longer relevant
- update code examples to meet current coding style rules
Triaging Issues and Pull Requests
One of the many ways that you can contribute is to help triage the list of pending issues.
When doing so you should may want to:
- Ask for more information if you believe the issue does not provide all the details required to solve it.
- Suggest labels to can help categorise issues.
- Flag issues that are stale or that should be closed.
- Review code.
Our Development Process
While our development of Moodle is managed in the Moodle Tracker, all development of these Developer Resources takes place in this GitHub repository. All work takes place in public, in this repository.
We make use of GitHub actions for our continuous integration and have a range of unit tests, end-to-end tests, style and lint tests, and build tests.
When creating a new issue, always make sure to fill out the issue template.
We use GitHub Issues for our documentation bugs. If you would like to report a problem, take a look around and see if someone already opened an issue about it. If you are certain this is a new, unreported bug, you can submit a bug report.
Please provide as much information as possible and, if you are able to, provide screenshots. Fixes are always welcomed.
If you would like to request documentation for new features, or the migration of documentation from the legacy devdocs you can use the appropriate issue templates.
For migrated documentation, if you can provide updated code examples, then this will make it easier to prioritise your issue.
We welcome contributions to these developer resources. If you've not contributed before and would like to do so, then you may like to look at our list of good first issues to get you started.
If you have domain-specific knowledge in an area which has outstanding documentation then the
help wanted search may give you some inspiration.
A set of writing and coding style guidelines for this documentation will be documented in more detail in the style guides.
See our linting and spelling documentation for more information on how to check for common issues.
All pull requests should be opened against the
main branch, and pushed to your own GitHub fork of the repository.
When you open your pull request we will automatically run a number of continuous integration jobs against your branch to check for errors and you'll be notified if any of these fail. We recommend looking out for any failures and fixing them as soon as you can.
The project maintainers will review your code and may provide feedback before it's merged into the project.
Every commit tells a story, and the commit message is the key narration of that story. It can be extremely useful to have a bit more information about your changes so try to provide any extra information that might be useful. For example:
- If you remove some old documentation, or part of a file, it may be useful to explain why it is no longer necessary.
- When you add a new documentation for a new feature, it may be useful to include the Moodle Tracker issue in your commit message to tie everything together.
- When noting the deprecation of a Moodle feature, it may be useful to include a link to the Moodle Tracker issue.
The first line of your commit should meet the following format:
[<type>] <area>: <subject>
We currently use the following types:
repo- For anything related to the repository, or documentation system
docs- For changes to the developer resource documentation itself
<area> tag is primarily used for
docs changes to describe the section of documentation you have made changes to.
Some of this documentation related to a specific version of Moodle:
general- This section is not documented at all
docs- Relates to the current Moodle development branch, known as
versioned_docs/version-X.Y- Related to a specific major version of Moodle
If you are documenting a feature which should be documented across older versions, we request that you backport it to the relevant stable versions.
By contributing to the Moodle Developer Resources, you agree that your contributions will be licensed under the GPLv3 license.
The following header should be present in all non-documentation code files:
* Copyright (c) Moodle Pty Ltd.
* Moodle is free software: you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation, either version 3 of the License, or
* (at your option) any later version.
* Moodle is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
* You should have received a copy of the GNU General Public License
* along with Moodle. If not, see <http://www.gnu.org/licenses/>.