Timeline for How to monitor code review efficiently?
Current License: CC BY-SA 3.0
8 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Mar 11, 2015 at 16:25 | comment | added | BЈовић | We did code reviews, but not on regular basis. I am just sharing my experience with such approach. | |
Mar 11, 2015 at 14:54 | comment | added | Agostino | @BЈовић was your team doing code reviews on a regular basis before? This technique is used by many, especially in the Open Source ecosystem. The fact it didn't work for your team does not mean if can't work for others. | |
Mar 11, 2015 at 10:50 | comment | added | BЈовић | I had a similar prohibit, and needless to say: the development almost stopped. That rule lasted whole 2 weeks, after which the managers had to adjust their plans. | |
Mar 11, 2015 at 8:31 | comment | added | Paŭlo Ebermann | Yes, it helped a bit by allowing the merge only for a limited set of people, who had the task to check if the actual review was done right. | |
Mar 11, 2015 at 0:07 | comment | added | Agostino | @PaŭloEbermann I see. I'm afraid that's an inevitable outcome of circumstances, if you don't have enough time to do everything you need to, quality will suffer, one way or another. Sill, if it does not work "sometimes", that means it works "most of the time", no? | |
Mar 10, 2015 at 20:57 | comment | added | Paŭlo Ebermann | Even with such a process (which I supposed actually happens from the description in the question), you sometimes have developers thinking "ah, I trust my colleague enough and have too much to do myself, so I'll just merge it without actually reading the details, or even commenting on it". (We have a similar process in our team, with two approvals needed (from people other than the PR author), before it can be merged. Still sometimes changes go through without a thorough review.) | |
Mar 10, 2015 at 19:43 | review | First posts | |||
Mar 10, 2015 at 20:44 | |||||
Mar 10, 2015 at 19:39 | history | answered | Agostino | CC BY-SA 3.0 |