Wow, we have 66 tickets waiting for review.... this is pretty bad. Something must definitely change.
>From my side, having a contributor shop around for a reviewer is not really fair. However, I would support the idea of Apache Ignite community electing a person responsible to find reviewers for all contributions. D. On Mon, Jun 5, 2017 at 11:23 AM, Dmitry Pavlov <dpavlov....@gmail.com> wrote: > 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? > > > >>>> > > > >>> > > > >> > > > > > > > > >
