Perth Hackfest October 2012/Understand the integrators

Revision as of 16:09, 30 October 2012 by Helen Foster (talk | contribs) (copied session notes from google doc)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
  • How do you feel about the process? Need feedback.
    • For situations in which there are more than one way to solve a problem, should it be the developer’s decision or the integrator’s or peer reviewer?
      • Need to have a conversation with pros and cons for each approach
      • Go into conflict resolution mode
      • Important that integrator doesn’t do development for developer
      • When rejected should be able to understand why it was rejected and learn from it.
    • Can we improve peer review stage?
      • Currently nobody focussing on external peer review
      • Integration team seem to be doing bulk of code reviewing
      • Some non-hq developers get stuck at peer review stage and force issues through to integration to get peer reviewed
        • Maybe have a dedicated peer review team. Should not be just Moodle HQ.
        • Can be a stepping point to get onto the integration team
        • Peer reviewer ideally should already have experience in that area of the code
        • Sometimes component leads don’t have time for peer reviewing everything assigned to them.
        • How to include more non HQ developers to do peer reviewing?
      • Need public peer review dashboard in tracker - would help emphasize the fact that peer review is not only for HQ devs
      • Currently no mechanism for prioritising issues waiting for peer review
      • Peer review meant to be quick and fast - spotting the most obvious bugs
    • Some documentation is not widely known, or not available yet, or not totally up to date
  • Links: Integration Review

Big thanks to all our integrators!