Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

How to change moodle


Published on

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

Published in: Education
  • Great presentation Sam - has already done the rounds of the NetSpot dev team :)
    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.
    Are you sure you want to  Yes  No
    Your message goes here

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>