Perth Hackfest October 2012/Technical Debt and Processes

http://salvetore.wordpress.com/2012/08/08/open-technical-debt/

https://docs.moodle.org/dev/Peer_reviewing_checklist including copy-able checklist

• A fifth of the stable team’s work is peer review
• 2 stable teams

• Suggestion: Add performance to peer review

• Re. value of tests - unit tests most valuable, then automated. Unit tests should not be an afterthought, novice devs should not be expected to write unit tests, Moodle hq devs should set example by always writing unit tests.

• From integrators POV, much easier to integrate something which has a unit test

• Technical debt => Work you create when you do other work
  • e.g. Activity chooser: get bugs, and new feature bits, etc
• Like taking out a loan
  • Borrowing time/labor => accumulates
  • Don't want it to accumulate too much or system becomes crap
• Developers
  • Create system with features
  • But still under control and manageable
    • Need to know about your technical debt and consequences
• Moodle HQ
  • Has seen increase in tracker issues reported, 20/issues day
    • But most tickets are by developers reporting debt/bugs
• 4 quadrants (http://salvetore.wordpress.com/2012/08/08/open-technical-debt/)
  • reckless, deliberate
    • We don't have time for design
  • reckless, inadvertent
    • What's layering?
  • prudent,,deliberate
    • We must ship now and deal with consequences
  • prudent,inadvertent
    • Now we know how we shave have done it
• Make sure you report technical debt in tracker
• "Report an error" button?
  • Full stack trace and recent log reports emailed to admin/Moodle.org
• Require phpunit tests for bug fixes?
  • Problem with developers new to Moodle might break something unrelated
  • Maybe Moodle HQ should be writing these unit tests?
  • Also, have functional tests, since not everything can be covered in a unit test

• JIRA searching
  • How to better search for duplicate issues -> often Google is better than JIRA search

• Priorities for HQ stable - blockers, security, partner, patched
  • Open “patched” issues don’t really have much attention paid to them, developers should be submitting their patches for peer review
  • Patched issues don’t always go in (for various reasons) but are still available in the tracker for anyone who wants the patch
    • “patch” tag should mean “waiting for peer review”
  • What is the time expectation for accepting/reviewing patches?
    • To get developers engaged, then getting patch accepted/reviewed quickly is essential
    • Tim Hunt triaged issues First In, First Out (FIFO)
    • Martin D. triaged issues with some balance between recently reported and older issues to get some users happy with quick turnaround
• How many components have leads?
  • 50% don’t have leads and many of component leads don’t triage issues
• Need shared peer review dashboard
• Developing new features
  • Should create issue in tracker, post forum discussion, create spec page in developer wiki, need to get dev voters
• http://tracker.moodle.org/browse/MDL?selectedTab=com.atlassian.jira.plugin.system.project%3Acomponents-panel tracker components
• There is a JIRA plugin to automatically add watchers to components http://tracker.moodle.org/browse/MDLSITE-1201
  • It was installed, but not in use
  • Would be useful to solve component lead problem, so that not one individual is responsible
• How to introduce new Moodle HQ developers
  • Mostly in developer chat - also in HQ group on moodle.org and tracker, but could do better?
• How Moodle HQ distributes information
  • Better in the last year
  • Integration roundups
  • Developer roadmap
  • Should share the dev calendar on moodle.org

Integrators Discussion

• Performance issues
  • Moodle HQ right now doesn’t have good, live data to debug performance issues
  • Needs people to contribute data
    • Would a written anonymizer work? More than just the user table. But legal problems can arise with giving user data, event to trusted parties.