|
|
| (22 intermediate revisions by 12 users not shown) |
| Line 1: |
Line 1: |
| 很多人问moodle的开发是怎么操作的.本页面将给你一个概览，帮助你理解许多其它的开发文档。
| | {{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 是Moodle项目的开发负责人. 通常他试着推行民主，推广精华知识，但是他也偶尔在一些事情上做是否可执行决定. | | ;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: 大部分是澳大利亚人的一个开发者团队，由Moodle项目提供资金，进行全职的moodle核心开发. 团队成员包括 Martin Dougiamas (moodler), Eloy Lafuente (stronk7), Petr Skoda (skodak), Mathieu Petit-Clair (scyrma), Nicolas Connault, Donsheng Cai, Jérôme Mouneyrac, Helen Foster (wildgirl) and occasionally Jamie Pratt (jamiesensei). 每个人的头像可以在这里找到: http://moodle.com/hq/. | | ;[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. |
|
| |
|
| ;Catalyst: 一个在新西兰的Catalyst Lid的开发团队，为Moodle的客户工作，进行许多核心开发。团队成员包括 Martin Langhoff, Penny Leach (mjollnir), Matt Clarkson, and Donal McMullan. | | ;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. |
|
| |
|
| ;Open University: 在英国Open University的一个主要负责Moodle安装实施的开发团队. 团队成员包括 Tim Hunt, Sam Marshall, Nick Freear, Thanh Le and Jenny Gray. | | ;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. |
|
| |
|
| 现在还有许多其它的人通过不同的方式来为moodle项目做贡献, 上面这些只是主要负责核心开发的团队。参考[http://moodle.org/cvs the full list of people with write access to Moodle]
| | 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. |
|
| |
|
| ==Moodle 版本== | | ==How we develop the Roadmap== |
|
| |
|
| Moodle大概每6个月或更长时间发行一个主版本，没有固定的日程。每个主版本将使Moddle的主版本号增加0.1. 在每个稳定分支上的次版本 (没有新的特性增加, 只是一些bug修改) 可能在任何时间发生,不管在任何时候，只要足够的bug修复经过验证即可.完整的细节可以在 [[Release notes]] 看到.
| | 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. |
|
| |
|
| 目前的开发版可以在CVS的trunk(i.e. HEAD)上找到, 稳定的分支版本将会分散出现在每个主版本中(e.g. MOODLE_18_STABLE).
| | Component leads decide on features in individual components so make your case to them! |
|
| |
|
| ==我们怎样开发 Roadmap== | | ==Moodle versions== |
|
| |
|
| [[Roadmap]] 列出将在下个版本中开发的特性. 这个列表主要源于在Moodle[[Tracker]]里在一些焦点问题上的大量投票，所以请为你想要的特性投票! 其它的包括公开讨论以及在Moodle Moots和Moodle论坛的特性请求也会对此列表有所影响。
| | 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]]. |
| ;Rapid Development: 几个月长时间的开发，主要为Moodle的HEAD版本添加代码.同时, 所有不涉及数据库改变以及基本核心改变的bug修复代码将会移植到最新的两到三个稳定分支版本.
| |
| ;Head Freeze: 在某种情况下，Martin Dougiamas 可能会宣布冻结新工作而去稳定核心代码. 所有的数据库改变和主要核心的改变需要获得Martin的明确允许. 所有的开发者应该封装他们在新特性上的工作，并修复在新代码中的bug。这段时间可能会有1到2个星期.（吃饭中，保存一下）
| |
| ;Beta period: 一旦HEAD版本变的相当稳定, Martin 将宣布一个BETA版本，被标记为MOODLE_XX_BETA (e.g. MOODLE_19_BETA).安装包会每日从最新版本生成以便通过跟踪进行更广泛的测试和反馈。Freeze将继续，测试和bug修复也将继续. 这个测试时间将花费2到6个星期
| |
| ;Major release: 当核心代码通过所有测试，我们就可以转向这个版本，MOODLE_XX_BETA标记将会被用来标记当前version作为一个分支，然后一个名叫MOODLE_XX_STABLE的新的稳定分支就产生了。包创建了，该发行版也将会被宣布。
| |
|
| |
|
| 然后，所有的又按照这个周期重新开始!
| | ==Support lifetime== |
|
| |
|
| ==Quality control==
| | 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. |
|
| |
|
| 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]].
| | That means we usually release minor versions for the last three major branches. |
|
| |
|
| 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.
| | 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. |
|
| |
|
| ===Testers=== | | ==Issue tracking== |
|
| |
|
| Testers are responsible for verifying the accuracy of changes made by developers. Testers choose which bugs they want to test, according to their area of expertise, and use the QA Assignee field to identify themselves as the tester.
| | 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]. |
|
| |
|
| If the bug passes testing, then the tester changes the status of the bug from 'resolved' to 'closed'. If the bug fails testing, or if the fix is incomplete, then the tester reopens the bug.
| | 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. |
| | |
| A Moodle release will be deemed ready when all "blocker" bugs fixed for a particular version have been closed.
| |
| | |
| | |
| ===Weekly Code Review===
| |
|
| |
|
| Every Tuesday (all time zones), testers and core developers stop developing new code and focus on reviewing changes made to the stable releases in the past week (both at a code level and an interface level).
| | ==Processes== |
|
| |
|
| This process is intended to improve the quality of the latest download packages and to catch any new bugs that might have been created while fixing old ones.
| | As you might guess, a large software project like Moodle with hundreds of contributors and varied opinions can be difficult to manage. |
|
| |
|
| The latest stable packages are tagged as MOODLE_19_WEEKLY (these tags are updated after the weekly review is over).
| | 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 [[Weekly Code Review]] for more details. | | See our [[Process]] document for full information on our development processes, including how you can contribute to the project. |
|
| |
|
| ==Coding Standards== | | ==Coding Standards== |
|
| |
|
| The full [[Coding|Coding Guide]] gives all the details, but here are some of the major things your code needs to hit:
| | 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. |
| | |
| ===XMLDB===
| |
| | |
| All our database schema are created using the XML ''install.php'' files, and upgraded using database-agnostic commands in ''upgrade.php'' files. Any version of any part of Moodle can be smoothly upgraded to any later version in this fashion (on a wide variety of supported databases).
| |
| | |
| ===XHTML===
| |
| | |
| All output from Moodle must be compliant with XHTML Strict 1.0, and also compliant with all common accessibility guidelines (such as W3C WAG).
| |
| | |
| ===Forms===
| |
| | |
| All forms should use the Moodleforms library if possible. This results in a standardised accessible output that designers can style consistently and well.
| |
| | |
| ===Parameters===
| |
| | |
| All parameters should be checked using require_param() and optional_param() which will safely clean all incoming data for use and provide defaults to your code. Moodleforms will do this automatically for you.
| |
| | |
| ===Output===
| |
| | |
| All textual output should be output using the format_text or format_string functions. This will ensure that text is cleaned and filtered appropriately.
| |
| | |
| ===Access===
| |
| | |
| All permissions-checking should use the "Access library" to check against current capabilities. The most common function you'll use is has_capability() which checks the permissions of the current user in an efficient way to see if they are allowed to do this specific operation. Do not check for specific roles in your code (e.g. teacher/student) as that will make your code useless.
| |
| | |
| ===Other core libraries===
| |
| | |
| The other major libraries you should get familiar with are:
| |
| # ''moodlelib.php'' - a useful bin of all kinds of useful functions and constants
| |
| # ''datalib.php'' - all the functions you need to interface with the database
| |
| # ''weblib.php'' - all the functions you'll need to create and output XHTML
| |
| | |
| | |
| ===Plugins===
| |
| | |
| Moodle has about 22 different types of plugins last time I counted. Plugins can generally be self-contained in a single directory containing scripts, images, stylesheets and language files all in one package that can be dropped into the Moodle script directory in the right place. After that the admin just needs to visit the admin page to install them.
| |
| | |
| Most plugins work in one of two ways, they either provide a ''lib.php'' filled with common functions and some scripts with standard names, or they subclass a proto-plugin and override a few method functions to achieve their goals.
| |
| | |
| The best way to learn is to pick an example from the core code that is similar to what you want to do and start playing with it. There are also some template plugins to help get you started.
| |
| | |
| ==Development processes==
| |
| Not all Moodle development happens exactly like this, but it really should. :-)
| |
| | |
| ===Major Development===
| |
| A major development is a significant piece of new code, adding new functionality to Moodle.
| |
| | |
| ====Make sure it's a good idea====
| |
| Firstly, you should look at the roadmap and talk the idea over with some Moodle developers to see if someone else is working on it already and whether others think the general idea has merit. Use the forums if you wish, or whatever means you have. If you have a client, you may need to work with them to work out what they REALLY want (perhaps it isn't actually a new development for Moodle).
| |
| | |
| ====Create a specification in Moodle Docs====
| |
| Start a new page in the Moodle Docs wiki, similar to [[Grades]]. Your page should outline the database table design, the GUI, the hows and whys etc. Include as much detail as you need (even mock screenshots) but try to keep it clear and logically organised.
| |
| | |
| ====Seek and absorb community feedback====
| |
| Post about the new page in the appropriate forums on [http://moodle.org/course/view.php?id=5 Using Moodle] to help draw attention to it and to stimulate some discussion around your development. The more feedback you have the better, especially if it includes a wide variety of users (developers, teachers, students etc).
| |
| | |
| Edit your page in response to the feedback, or invite people to do so themselves. try to evolve the specification into something that all users are happy with. Sometimes it's worth working harder to find the "best" way to do something without adding Yet Another Option.
| |
| | |
| ====Set up tasks in the Moodle Tracker====
| |
| Once the specification has settled down, it's time to start work. Create a new task for yourself in the Moodle Tracker, and add sub-tasks in roughly chronological order for all the different parts of the job. This not only helps you keep track of where you are, but allows the community to "watch you" develop and to help you where they can. If there are different people working on different parts, you can assign subtasks to different people. It's really very convenient to use once you get the hang of it.
| |
| | |
| ====Use CVS and link commits to Tracker====
| |
| If possible, develop the code in an open code repository (and preferably Moodle CVS!). If you need CVS write access to the core code or the contrib repository, use the "Apply for CVS Access" tab on http://moodle.org/cvs. Gaining access to the main core code is quite difficult, but we are generally very free with access to the contrib area.
| |
| | |
| Every time you make a commit, include a detailed message about the new code and always include a Moodle Tracker bug number (e.g. MDL-7777). This will ensure that the Moodle Tracker is able to detect your commit and attach it to the relevant bug report.
| |
| | |
| ====Comment on milestones in forums and tracker====
| |
| If you hit a major milestone, or want testers to try something, feel free to post about it in the relevant forum on Using Moodle. The more people you can attract to look and try out your code the better it will be, trust me.
| |
| | |
| ====Respond to bug reports====
| |
| Of course you need to listen to your users (well, most of them :-)). Encourage people to file bugs, and fix them. If you need help setting up a project category in the Tracker contact support@moodle.com. This will ensure that all your bugs are easy to find and to track.
| |
| | |
| ===Minor Development===
| |
| | |
| For smaller modules, fixes, improvements and other issues.
| |
| | |
| ====Create a new issue in the tracker====
| |
| | |
| You should definitely create an issue in the tracker to describe your development and to act as a focus point for all discussion. You can reference the bug number from forum discussions and in commit messages etc. This way everyone can easily find out exactly what they are talking about.
| |
| | |
| ====Attach a patch====
| |
|
| |
|
| If you have some code, please attach it to the tracker issue, or if it's on your own site then link to it from the tracker issue. Don't attach code in the Moodle forums ... it will "rot" quickly there and just clogs up moodle.org with useless old code.
| | ==Plugins and APIs== |
|
| |
|
| ====Promote the patch====
| | 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. |
|
| |
|
| By all means draw attention to your work in the Moodle forums (mentioning the bug number) or email developers directly to help make them aware of it. You can also add developers as "watchers" to the tracker issue if you want, this means they will get email for every change on the issue.
| | See our [[Plugins|Plugin documentation]] for full details of the various types of plugin available. |
|
| |
|
| ==See also== | | ==See also== |
| Line 153: |
Line 64: |
| * [[Finding your way into the Moodle code]] | | * [[Finding your way into the Moodle code]] |
| * [[Working with the Community]] | | * [[Working with the Community]] |
| * [[Guidelines for contributed code]] | | * [[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:Overview]] | | [[Category:Quality Assurance|Overview]] |
| [[Category:Quality Assurance]] | | [[Category:Processes|Overview]] |
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.
See also
