Perth Hackfest October 2012/Understand the integrators
From MoodleDocs
- 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?
- Here is a checklist: Peer reviewing checklist
- Maybe use code review tool like: gerrit: http://code.google.com/p/gerrit/
- Not scalable for large teams like Moodle -> learning curve and extra step in process
- 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
- sql guidelines
- Category:Coding guidelines
- Peer_reviewing checklist
- 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?
- Links: Integration Review
Big thanks to all our integrators!
