In general, I tend to agree with Anton that something needs to be changed in this direction.
How many of you flip through dev list, JIRA or GitHub notifications in an attempt to find tickets that demand your attention? I bet the percentage is pretty low. To solve this issue I see two options: 1) Proposed by Anton. 2) Having a guy in the community who’ll keep an eye on all the incoming pull-requests shuffling them between committer in the same way proposed in 1. Personally, I’m for 1. — Denis > On Jun 5, 2017, at 10:28 AM, Dmitry Pavlov <dpavlov....@gmail.com> wrote: > > 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? >>>> >>> >>
