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