Overview: Difference between revisions
No edit summary |
Dev Docs Bot (talk | contribs) m (Protected "Overview": Developer Docs Migration ([Edit=Allow only administrators] (indefinite))) |
||
| (50 intermediate revisions by 18 users not shown) | |||
| Line 1: | Line 1: | ||
A lot of people ask how the development of Moodle operates. | {{Template:Migrated|newDocId=/general/community}} | ||
A lot of people ask how the development of Moodle operates. This page should give you a working overview that should help in understanding a lot of other developer documentation. | |||
==The key players== | |||
;Martin Dougiamas: Martin is the founder lead developer of Moodle. Generally he tries to facilitate democracy and meritocracy but occasionally has to make executive decisions on things. | |||
;[https://moodle.com/careers/ Moodle HQ]: The team of more than 20 developers who are directly funded by the Moodle project to work full-time on core developments. | |||
;Moodle Partners: Over 50 companies around the world that provide Moodle services. These companies often have their own developers and may contribute to Moodle directly by working on core code or by creating plugins. | |||
; | ;Component leads: A number of people around the world have volunteered to lead various components in Moodle. This involves maintaining existing code as well as listening to the community and improving that component with new features. | ||
There are many other people contributing to Moodle in many ways. For a full list see the [http://moodle.org/local/dev/ Moodle developers] page on moodle.org. | |||
==How we develop the Roadmap== | |||
The [[Roadmap]] lists the new features being developed for the next major version. This list is derived mostly from the issues with large numbers of votes in the Moodle [[Tracker]], so please vote for what you want! Other influences include general discussion, surveys and feature requests at Moodle Moots and in the Moodle forums. | |||
Component leads decide on features in individual components so make your case to them! | |||
==Moodle versions== | ==Moodle versions== | ||
Moodle major releases | Moodle major releases (with big new features) are on a regular 6 month cycle, in May and November, since Moodle 2.6. Each major release increments the version number by 0.1 (eg 3.4 -> 3.5 -> 3.6)) and starts a new branch of minor releases. | ||
Minor releases (with bug fixes only) are on a 2 month cycle, unless a security emergency occurs. They will increment the major release by 0.0.1 (eg 3.5 -> 3.5.1 -> 3.5.2). | |||
The full details of these can be seen in the [[Releases]]. | |||
==Support lifetime== | |||
Moodle HQ is committed to supporting major releases for 12 months of general fixes (usually 6 point releases) and 18 months (an additional 6 months) of security fixes. | |||
That means we usually release minor versions for the last three major branches. | |||
Some versions, every two years, are [https://en.wikipedia.org/wiki/Long-term_support long term supported (LTS)] for a total of 36 months, with 18 additional months of security fixes compared to other versions. | |||
==Issue tracking== | |||
Issue tracking is an important part of a continuous quality control process. It involves reporting of problems (bugs), ideas for improvement and new features. Unlike most proprietary software programs, Moodle issue reporting and tracking information is open to everyone. Moodle's issue tracking system is called the [http://tracker.moodle.org/ Tracker]. | |||
== | All Moodle users are encouraged to be active participants when it comes to testing. Anyone with a Tracker user account can create, view, comment on, vote, and watch bugs. | ||
==Processes== | |||
As you might guess, a large software project like Moodle with hundreds of contributors and varied opinions can be difficult to manage. | |||
Over time we have developed a number of well-defined processes for getting code in and out of Moodle and for governing everyone's workflow in a way that is fair and clear. | |||
See our [[Process]] document for full information on our development processes, including how you can contribute to the project. | |||
==Coding Standards== | ==Coding Standards== | ||
== | Over time we have distilled our best practice in writing code down into our [[Coding|Coding Guide]]. These rules cover the formatting and layout of all our code to make it consistent across the code base. If you plan to write Moodle code, you need to read it thoroughly. | ||
==Plugins and APIs== | |||
Although Moodle is open source and you can change anything you want, the best and most maintainable way to extend Moodle is to write a plugin (sometimes called a module). Plugins are a directory of code that can be simply "dropped" in into any Moodle installation and it will be detected, installed and automatically made available as a tool within the Moodle interface. | |||
See our [[Plugins|Plugin documentation]] for full details of the various types of plugin available. | |||
== | ==See also== | ||
* [[Finding your way into the Moodle code]] | |||
* [[Working with the Community]] | |||
* [[Plugin contribution]] | |||
* [http://www.slideshare.net/poltawski/how-to-guarantee-your-change-is-integrated-to-moodle-core How to guarantee your change is integrated to Moodle core] presentation by Dan Poltawski | |||
[[Category:Quality Assurance|Overview]] | |||
[[Category:Processes|Overview]] | |||
Latest revision as of 07:27, 6 May 2022
| Important:
This content of this page has been updated and migrated to the new Moodle Developer Resources. The information contained on the page should no longer be seen up-to-date. Why not view this page on the new site and help us to migrate more content to the new site! |
A lot of people ask how the development of Moodle operates. This page should give you a working overview that should help in understanding a lot of other developer documentation.
The key players
- Martin Dougiamas
- Martin is the founder lead developer of Moodle. Generally he tries to facilitate democracy and meritocracy but occasionally has to make executive decisions on things.
- Moodle HQ
- The team of more than 20 developers who are directly funded by the Moodle project to work full-time on core developments.
- Moodle Partners
- Over 50 companies around the world that provide Moodle services. These companies often have their own developers and may contribute to Moodle directly by working on core code or by creating plugins.
- Component leads
- A number of people around the world have volunteered to lead various components in Moodle. This involves maintaining existing code as well as listening to the community and improving that component with new features.
There are many other people contributing to Moodle in many ways. For a full list see the Moodle developers page on moodle.org.
How we develop the Roadmap
The Roadmap lists the new features being developed for the next major version. This list is derived mostly from the issues with large numbers of votes in the Moodle Tracker, so please vote for what you want! Other influences include general discussion, surveys and feature requests at Moodle Moots and in the Moodle forums.
Component leads decide on features in individual components so make your case to them!
Moodle versions
Moodle major releases (with big new features) are on a regular 6 month cycle, in May and November, since Moodle 2.6. Each major release increments the version number by 0.1 (eg 3.4 -> 3.5 -> 3.6)) and starts a new branch of minor releases.
Minor releases (with bug fixes only) are on a 2 month cycle, unless a security emergency occurs. They will increment the major release by 0.0.1 (eg 3.5 -> 3.5.1 -> 3.5.2).
The full details of these can be seen in the Releases.
Support lifetime
Moodle HQ is committed to supporting major releases for 12 months of general fixes (usually 6 point releases) and 18 months (an additional 6 months) of security fixes.
That means we usually release minor versions for the last three major branches.
Some versions, every two years, are long term supported (LTS) for a total of 36 months, with 18 additional months of security fixes compared to other versions.
Issue tracking
Issue tracking is an important part of a continuous quality control process. It involves reporting of problems (bugs), ideas for improvement and new features. Unlike most proprietary software programs, Moodle issue reporting and tracking information is open to everyone. Moodle's issue tracking system is called the Tracker.
All Moodle users are encouraged to be active participants when it comes to testing. Anyone with a Tracker user account can create, view, comment on, vote, and watch bugs.
Processes
As you might guess, a large software project like Moodle with hundreds of contributors and varied opinions can be difficult to manage.
Over time we have developed a number of well-defined processes for getting code in and out of Moodle and for governing everyone's workflow in a way that is fair and clear.
See our Process document for full information on our development processes, including how you can contribute to the project.
Coding Standards
Over time we have distilled our best practice in writing code down into our Coding Guide. These rules cover the formatting and layout of all our code to make it consistent across the code base. If you plan to write Moodle code, you need to read it thoroughly.
Plugins and APIs
Although Moodle is open source and you can change anything you want, the best and most maintainable way to extend Moodle is to write a plugin (sometimes called a module). Plugins are a directory of code that can be simply "dropped" in into any Moodle installation and it will be detected, installed and automatically made available as a tool within the Moodle interface.
See our Plugin documentation for full details of the various types of plugin available.
