DEV Community

Discussion on: The Problem with Feature Branches

 
netch80 profile image
Valentin Nechayev

(Replying here, because replies to previous comments are closed - is it engine feature or deliberate action?)
The rule that, by default, merge of pull request should be done by a person who created it, is proper because that person has been most thinking on code and so sees all its peculiar: decisions made, peculiars, tradeoffs, etc. Reviewers, normally, shall approve or disapprove, but don't make final decision to merge. Anyway, the system keeps proposals and allows to get them later on.
There should be cases somebody other merges a proposal (pull request, etc.) but under special circumstances (author is on vacation / gone / sick, or there is a flaming need to merge for a release and team lead takes ownership on the merge).

For desynchronization issue (typical e.g. between USA, Europe and India team), well, in a normal situation, 1-day delay is not critical under well-established processes. But what I consider more important that
1) There shall be strict requirement on regular time band dedicated by each developer for review process. For example, up to 2 hours each working day when there are pending reviews. Only critical issues should be more important than peer review.
2) The need to review shall be easily checked by a developer. (Mail, dashboard, etc.)
3) Developer tools shall be adapted to alleviate review process as much as possible, including such cases as commit sequences, proposal versions, CI assistance.