How to change Moodle: working with Moodle HQ sam marshall / The Open University
Contents <ul><li>Moodle 1 – hack hack hack </li></ul><ul><ul><li>Good idea to work with Moodle, not against it... </li></u...
Fear leads to anger <ul><li>Moodle 1.6 can’t do what our course teams demand. </li></ul><ul><ul><li>‘No’ is the hardest wo...
Anger leads to hate <ul><li>Whenever we needed something we did a core hack. </li></ul><ul><ul><li>Policy to mark these, b...
Hate leads to the dark side <ul><li>Approx  2,268  OU-specific changes in core parts of OU Moodle 1.9.10 </li></ul><ul><li...
Hallelujah! Moodle 2 <ul><li>This time let’s do it properly </li></ul><ul><li>Policy to minimise OU-specific changes </li>...
Moodle HQ process <ul><li>New process applies to everyone (including HQ themselves). </li></ul><ul><li>Short version of de...
Process in practice <ul><li>Tracker, sometimes Moodle docs – post proposal </li></ul><ul><li>General developer forum – mak...
Case study: module display <ul><li>New core feature necessary for our plugins </li></ul><ul><li>Without this, only Forum c...
Selling points <ul><li>Acceptable  for Moodle HQ </li></ul><ul><ul><li>Doesn’t change existing behaviour </li></ul></ul><u...
First attempt <ul><li>Wrote code for one part of this </li></ul><ul><ul><li>Implemented minimal clean change </li></ul></u...
Second attempt <ul><li>Initial discussion in chat with Petr </li></ul><ul><ul><li>Nick Thompson from UCLA also contributed...
Third attempt <ul><li>Rewrote spec based on Petr’s comments </li></ul><ul><ul><li>Again made change less minimal </li></ul...
Actual coding <ul><li>Able to reuse  some  aspects of previous code </li></ul><ul><li>High quality  code </li></ul><ul><ul...
Follow-up <ul><li>Code finally accepted and integrated into Moodle 2.0.2 </li></ul><ul><li>Helped promptly with bugs </li>...
Key points <ul><li>Lot of work  compared to just writing code </li></ul><ul><li>Difficult  to get HQ  developer attention ...
Conclusion <ul><li>Final version much  better  than original plan (thanks to Petr Škoda and others) </li></ul><ul><li>Wort...
Upcoming SlideShare
Loading in …5
×

How to change moodle

3,183 views

Published on

UK MoodleMoot 2011 presentation about developing new Moodle features in conjunction with Moodle HQ.

Published in: Education
2 Comments
2 Likes
Statistics
Notes
  • Great presentation Sam - has already done the rounds of the NetSpot dev team :)
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Note: Due to a bug in slideshare this is not displaying the last bullet point on the black slide. It was some stats about how successful our Moodle 1.9 system is despite all the negative issues I have been exaggerating; i.e. serving up to a million page requests per day, half a million new forum posts made each month, etc.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
3,183
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
11
Comments
2
Likes
2
Embeds 0
No embeds

No notes for slide

How to change moodle

  1. 1. How to change Moodle: working with Moodle HQ sam marshall / The Open University
  2. 2. Contents <ul><li>Moodle 1 – hack hack hack </li></ul><ul><ul><li>Good idea to work with Moodle, not against it... </li></ul></ul><ul><li>Moodle 2 – negotiate negotiate negotiate </li></ul><ul><ul><li>One experience with Moodle HQ’s new contribution process </li></ul></ul>
  3. 3. Fear leads to anger <ul><li>Moodle 1.6 can’t do what our course teams demand. </li></ul><ul><ul><li>‘No’ is the hardest word </li></ul></ul><ul><ul><li>Often they have good reasons to want things </li></ul></ul><ul><ul><ul><li>Other times it is pedagogically vital that a particular heading should be green </li></ul></ul></ul><ul><li>Will we be able to release like this? </li></ul><ul><li>GRRR </li></ul>
  4. 4. Anger leads to hate <ul><li>Whenever we needed something we did a core hack. </li></ul><ul><ul><li>Policy to mark these, but not really to limit them </li></ul></ul><ul><li>Even some of our plugins didn’t mesh well with Moodle code </li></ul><ul><li>I am leaving positive bits out to make this less boring </li></ul><ul><ul><li>We actually did work with Moodle HQ primarily by funding them to develop new features we needed (roles, accessible forms, gradebook). </li></ul></ul>
  5. 5. Hate leads to the dark side <ul><li>Approx 2,268 OU-specific changes in core parts of OU Moodle 1.9.10 </li></ul><ul><li>Point version upgrade = significant manual effort </li></ul><ul><li>Some OU plugins depend on those OU-specific changes, while community plugins don’t support them; harder to share with community </li></ul><ul><li>System does actually work; serves up to a million pages in a day, half a million new forum posts in a month, etc. </li></ul>
  6. 6. Hallelujah! Moodle 2 <ul><li>This time let’s do it properly </li></ul><ul><li>Policy to minimise OU-specific changes </li></ul><ul><ul><li>We get to say ‘no’ to course team requests! </li></ul></ul><ul><ul><ul><li>Sometimes </li></ul></ul></ul><ul><ul><li>Required features done as plugins, not core hacks </li></ul></ul><ul><li>When we do need core changes, try hard to get these into standard Moodle </li></ul>
  7. 7. Moodle HQ process <ul><li>New process applies to everyone (including HQ themselves). </li></ul><ul><li>Short version of development process: </li></ul><ul><ul><li>Do the code and make it public (GitHub) </li></ul></ul><ul><ul><li>Get maintainer / someone with access to review and submit a PULL request </li></ul></ul><ul><ul><li>Code reviewed and integrated / rejected by HQ </li></ul></ul><ul><li>Long version: Development:Process on Moodle Docs. </li></ul>
  8. 8. Process in practice <ul><li>Tracker, sometimes Moodle docs – post proposal </li></ul><ul><li>General developer forum – make public, gather support </li></ul><ul><li>Developer Jabber chat – pester developers (HQ and other) to comment on your general proposal </li></ul><ul><ul><li>If not generally approved, change and discuss until it is, or give up </li></ul></ul><ul><ul><li>If generally approved, code it and do PULL request </li></ul></ul><ul><ul><ul><li>When rejected with comments, make changes then submit another PULL request </li></ul></ul></ul>
  9. 9. Case study: module display <ul><li>New core feature necessary for our plugins </li></ul><ul><li>Without this, only Forum could display ‘Unread’ or similar status message on course page. </li></ul><ul><ul><li>‘ForumNG’ replacement </li></ul></ul><ul><li>Without this, only Label could display content on course page instead of just a link. </li></ul><ul><ul><li>RSS feed on course page </li></ul></ul>
  10. 10. Selling points <ul><li>Acceptable for Moodle HQ </li></ul><ul><ul><li>Doesn’t change existing behaviour </li></ul></ul><ul><ul><li>No significant performance problem </li></ul></ul><ul><li>Beneficial for Moodle HQ </li></ul><ul><ul><li>Clean up nasty hacks specific to Forum, Label </li></ul></ul><ul><ul><li>Some minor performance gains possible </li></ul></ul><ul><li>Desirable feature (not just by us) </li></ul><ul><ul><li>Lets plugins do cool things </li></ul></ul>
  11. 11. First attempt <ul><li>Wrote code for one part of this </li></ul><ul><ul><li>Implemented minimal clean change </li></ul></ul><ul><li>PULL request rejected by Petr Škoda! </li></ul><ul><ul><li>Fairly significant change (possible risks) </li></ul></ul><ul><ul><li>Didn’t have enough benefits </li></ul></ul><ul><ul><ul><li>Didn’t go far enough ! </li></ul></ul></ul>
  12. 12. Second attempt <ul><li>Initial discussion in chat with Petr </li></ul><ul><ul><li>Nick Thompson from UCLA also contributed </li></ul></ul><ul><li>Wrote detailed spec covering all aspects (not the ‘one at a time’ minimal change approach) on Moodle Docs </li></ul><ul><ul><li>Pestered on chat for comments </li></ul></ul><ul><li>Petr had significant comments </li></ul>
  13. 13. Third attempt <ul><li>Rewrote spec based on Petr’s comments </li></ul><ul><ul><li>Again made change less minimal </li></ul></ul><ul><ul><li>New change achieves some of Petr’s goals </li></ul></ul><ul><ul><ul><li>Fixes something that was bugging him: new classes now allow documentation, code completion </li></ul></ul></ul><ul><ul><ul><li>Additional benefit for HQ </li></ul></ul></ul><ul><ul><li>Still achieves all our goals too </li></ul></ul><ul><li>Pestered some more, got agreement. </li></ul>
  14. 14. Actual coding <ul><li>Able to reuse some aspects of previous code </li></ul><ul><li>High quality code </li></ul><ul><ul><li>Followed coding guidelines </li></ul></ul><ul><ul><li>Included thorough in-code documentation </li></ul></ul><ul><ul><li>Aim to be better than existing Moodle code </li></ul></ul><ul><ul><ul><li>‘lots of code already in Moodle is worse than this’ is not a good reason to accept commit </li></ul></ul></ul><ul><li>Did significant testing and wrote test plan </li></ul>
  15. 15. Follow-up <ul><li>Code finally accepted and integrated into Moodle 2.0.2 </li></ul><ul><li>Helped promptly with bugs </li></ul><ul><li>Wrote clear developer documentation on Moodle Docs </li></ul><ul><li>Hopefully this means HQ won’t hate me and are likely to be positive about future changes </li></ul>
  16. 16. Key points <ul><li>Lot of work compared to just writing code </li></ul><ul><li>Difficult to get HQ developer attention </li></ul><ul><ul><li>Identify benefits for HQ (fit in with existing aims) </li></ul></ul><ul><li>Bend over backwards to meet concerns, keep big developer ego in check </li></ul><ul><ul><li>They don’t need the feature, we do </li></ul></ul><ul><ul><li>We’re making work for them  </li></ul></ul><ul><li>Minimal change not always the best one </li></ul>
  17. 17. Conclusion <ul><li>Final version much better than original plan (thanks to Petr Škoda and others) </li></ul><ul><li>Worth doing – changes in this key part of core code are very risky/difficult to deal with local hacks </li></ul><ul><li>Think hard first – if you can do without a core change, you’ll save work </li></ul><ul><ul><li>Organisations: make sure you’re in a position to say no to non-critical features! </li></ul></ul>

×