Hi Igniters, Anton, Let’s imagine that development process as a chain of production stages 1) Developing patch by contributor 2) Review changes by committer
Reviews waiting too long time to be done at stage 2 may indicate that speed (potential throughput) of step 2 is less than throughput at step 1. T2<T1 In terms of this model (inspired by Goldratt’s Theory of Constraints (TOC)), I have a question: Will this responsibility movement (to find appropriate reviewer to contributor) help us to increase overall throughput? If we agree constraint in terms of TOC is throughput T2, I suggest following steps - Increase the throughput T2 of the committers - Reduce the load on the committers by improve quality of code after stage 1 given to review (pre review by non-committer, automatic review, code inspections) Best Regards, Dmitriy Pavlov пн, 5 июн. 2017 г. в 18:28, Anton Vinogradov <a...@apache.org>: > Igniters, > > Currently, according to > > https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-SubmittingforReview > , > contributor can ask for review by moving ticket to PATCH AVAILABLE state. > > And, as far as I can see, this cause broken tickets issue. > Contributor can wait somebody who'll review his changes for a month or even > more. > > I propose to change workflow and *make contributor responsible to find > reviewer*. > It's pretty easy to find a person able to review changes in most of cases. > > 1) You can check git history of files you modified and find persons with > expertise in this code > 2) In case you have problems with such search you can always use > maintainers list ( > > https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-ReviewProcessandMaintainers > ) > > Thoughts? >
