https://docs.moodle.org/dev/index.php?title=Perth_Hackfest_October_2012/Understand_the_integrators&feed=atom&action=historyPerth Hackfest October 2012/Understand the integrators - Revision history2024-03-28T09:32:19ZRevision history for this page on the wikiMediaWiki 1.39.6https://docs.moodle.org/dev/index.php?title=Perth_Hackfest_October_2012/Understand_the_integrators&diff=35966&oldid=prevTsala: copied session notes from google doc2012-10-30T16:09:40Z<p>copied session notes from google doc</p>
<p><b>New page</b></p><div>* How do you feel about the process? Need feedback.<br />
** 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?<br />
*** Need to have a conversation with pros and cons for each approach<br />
*** Go into conflict resolution mode<br />
*** Important that integrator doesn’t do development for developer<br />
*** When rejected should be able to understand why it was rejected and learn from it.<br />
** Can we improve peer review stage?<br />
*** Currently nobody focussing on external peer review<br />
*** Integration team seem to be doing bulk of code reviewing<br />
*** Some non-hq developers get stuck at peer review stage and force issues through to integration to get peer reviewed<br />
**** Maybe have a dedicated peer review team. Should not be just Moodle HQ.<br />
**** Can be a stepping point to get onto the integration team<br />
**** Peer reviewer ideally should already have experience in that area of the code<br />
**** Sometimes component leads don’t have time for peer reviewing everything assigned to them. <br />
**** How to include more non HQ developers to do peer reviewing?<br />
***** Here is a checklist: [[Peer reviewing checklist]] <br />
***** Maybe use code review tool like: gerrit: [http://code.google.com/p/gerrit/ http://code.google.com/p/gerrit/]<br />
****** Not scalable for large teams like Moodle -> learning curve and extra step in process<br />
*** Need public peer review dashboard in tracker - would help emphasize the fact that peer review is not only for HQ devs<br />
*** Currently no mechanism for prioritising issues waiting for peer review<br />
*** Peer review meant to be quick and fast - spotting the most obvious bugs<br />
** Some documentation is not widely known, or not available yet, or not totally up to date<br />
*** sql guidelines <br />
*** [[:Category:Coding guidelines]]<br />
*** [[Peer_reviewing checklist]] <br />
* Links: [[Integration Review]]<br />
<br />
''Big thanks to all our integrators!''</div>Tsala