1) There is waiting for review list here https://cwiki.apache.org/confluence/display/IGNITE/Issues+waiting+for+review
2) some of contributions are supplemented by dev-list messages (please review my PR…) And these two tools sometimes do not help. I suppose it is because of reviewers already have some things to do, but not because of lack of tool support. Do you have other explanations? But still, Igor’s suggestion to notify to dev list sounds reasonable to me. Anton, could it solve your requirement to know about issue needed to review? пн, 5 июн. 2017 г. в 21:06, Igor Sapego <isap...@gridgain.com>: > By the way, there are emails being sent from Jira to devlist every > time someone adds comment to ticket, or, for example, edits its > title which helps a lot to keep a track of ticket's state. > > But by some reason there is no such notification when ticket silently > getting moved to "Patch available" state. I believe, that would help if > there was a notification for that. Is it possible to configure? > > Best Regards, > Igor > > On Mon, Jun 5, 2017 at 9:00 PM, Denis Magda <dma...@apache.org> wrote: > > > 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? > > >>>> > > >>> > > >> > > > > >
