Hi Anton,
It is ok for me if it is advice and hint for faster review, as it is now. We can periodically remind about this opportunity at dev list or in the issue comments. We can remind that tasks in patch available status may be reassigned by contributor. Looking from prospective of overall throughput: it is not clear for me how this process change will help. Best Regards, Dmitriy Pavlov пн, 5 июн. 2017 г. в 20:16, Anton Vinogradov <a...@apache.org>: > Vova, > > Contributors interested to make contributions and I propose them to use > *same* strategy as we (people inside the community) use. > "-1" will not solve this issue, but my "tips" will. > > Dmitry, > > The main problem here is that nobody notified that someone is waiting for > the review. > It's not a problem for me to provide tips or to make review, but it's > problem to periodically check is there somebody waiting. > > Guys, > Let's try this approach, and I'm pretty sure it will help. > > On Mon, Jun 5, 2017 at 7:58 PM, Dmitry Pavlov <dpavlov....@gmail.com> > wrote: > > > 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? > > > > > >
