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? > > >
