Having some policy that we agree upon may be sensible.
Some suggestions, such as relying on the type of topic/patch, are interesting to accommodate the process.
Having a deadline or “slow down” button, requiring the approval of some maintainers, or a number of people, etc. seem desirable also.
But implementing these in GitHub
(remember that ITK is transitioning to GitHub) or requiring the GitHub
people do it may not be easy/out of reach.
Having said that, the truth is that:
-
Current maintainers are mostly based in the US, and accommodating different time zones may not be that easy, and workdays may also differ across countries, across companies, etc.
So this will inevitably happen.
-
We should acknowledge that maintainers’ institutions may also have other constraints (funding agencies, etc.) that one, including me, as a community member, may be unaware of.
-
People having push access are trustworthy and work to the best of their possibilities, including outside work hours, to make ITK better for the community , and the funding agencies, institutions, scientific community. Even if this means merging within short delays.
-
A good feature, module, class or awesome contribution in terms of bug fixes can beat missing a review. So there is always a chance to improve ITK !!
Just a short explanation @Niels_Dekker: the gerrit
review system automatically adds people as reviewers when it detects that a given user made some commit on the file at issue at some point in history.