Re: "Review workflow" changes to prevent "broken review" issues.
Igniters, Dmitry, basically agree It's no secret that Ignite is a very complex project, and contributors need a very high experience to become a committer. But this is a potential problem for scaling the community and project development. I think that one of the options for solving the growth problem could be to decompose issues for new contributors. This will allow them to be included in the project more quickly, and it will be more convenient for the committers to code review. There are cons, but what do you think? 2017-06-05 19:58 GMT+03:00 Dmitry Pavlov: > 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 > 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 : > > > 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? > > > -- Best Regards, Anton Churaev
Re: "Review workflow" changes to prevent "broken review" issues.
Page updated. On Wed, Jun 7, 2017 at 1:33 PM, Anton Vinogradovwrote: > Dmitriy, > > Got it, > I'll add this as an optional "Tips to pass review quickly". > > On Tue, Jun 6, 2017 at 7:11 PM, Dmitriy Setrakyan > wrote: > >> On Tue, Jun 6, 2017 at 7:40 AM, Anton Vinogradov < >> avinogra...@gridgain.com> >> wrote: >> >> > Igniters, >> > >> > Since we found that proposed approach can help, >> > no one mind that I'll add text listed above to the wiki? >> > >> >> I don't think that we have an agreement yet. Again, I still don't think it >> is fair for a contributor to find a committer that has a relevant area of >> expertise. A contributor should feel free to ask any committer for a >> review, but it should not be mandatory. I would rather have an existing >> contributor or committer help with finding a reviewer. >> >> >> > >> > On Tue, Jun 6, 2017 at 1:19 PM, Anton Vinogradov < >> avinogra...@gridgain.com >> > > >> > wrote: >> > >> > > Dmitry, >> > > >> > > 1) See my initial email, it contains instruction how to find a >> reviewer. >> > > And it's pretty easy to do when you have something to review (you did >> > some >> > > code changes). >> > > >> > > I want to add following to our wiki: >> > > >> > > " >> > > Ask commiter to review changes. >> > > Check affected file's git history to find commiter most likely able to >> > > review changes. >> > > In case it's hard to determine who's able to review by git history use >> > > maintainers list presented above. >> > > Add "review request" comment to the ticket starting with a commiter >> > > username. >> > > >> > > for example: "[~avinogradov], Please review my changes." >> > > >> > > Commiter will gain notification and review your changes and/or find >> > > another commiter to do this. >> > > >> > > Important: Each comment should be started with [~username]. >> > > " >> > > >> > > 2) It will be a huge help to the community! >> > > >> > > On Tue, Jun 6, 2017 at 1:12 PM, Dmitry Pavlov >> > > wrote: >> > > >> > >> Anton, >> > >> >> > >> >> > >> Thank you for explanation. Personal ask instead of group broadcast >> may >> > >> really help. I understand the idea now. >> > >> >> > >> >> > >> One argument against solution way 1) it may be not easy for >> contributor, >> > >> especially newcomer, to find a right person. >> > >> >> > >> >> > >> What do you think about way 2? Personally, I'm ready to help with >> > analysis >> > >> and assignment of these 66 tasks from next week. >> > >> >> > >> >> > >> >> > >> вт, 6 июн. 2017 г. в 12:57, Anton Vinogradov < >> avinogra...@gridgain.com >> > >: >> > >> >> > >> > Dmitry Pavlov, >> > >> > >> > >> > There is *HUGE *difference between "Devlist, please review my >> changes" >> > >> > and "Dmitry Pavlov, please review my changes". >> > >> > >> > >> > In case you're busy right now, you'll, most likely, ignore appeal >> to >> > >> > devlist, but, I'm pretty sure, you'll check appeal to yourself. >> > >> > Am I right? >> > >> > >> > >> > So, my idea is: appeal to devlist is a useless spam maker approach, >> > but >> > >> > appeal to person(s) works. >> > >> > >> > >> > On Tue, Jun 6, 2017 at 2:40 AM, Dmitriy Setrakyan < >> > >> dsetrak...@apache.org> >> > >> > wrote: >> > >> > >> > >> > > 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 > >: >> > >> > > > >> > >> > > > > By the way, there are emails being sent from Jira to devlist >> > every >> > >> > > > > time someone adds comment to ticket, or,
Re: "Review workflow" changes to prevent "broken review" issues.
Dmitriy, Got it, I'll add this as an optional "Tips to pass review quickly". On Tue, Jun 6, 2017 at 7:11 PM, Dmitriy Setrakyanwrote: > On Tue, Jun 6, 2017 at 7:40 AM, Anton Vinogradov > > wrote: > > > Igniters, > > > > Since we found that proposed approach can help, > > no one mind that I'll add text listed above to the wiki? > > > > I don't think that we have an agreement yet. Again, I still don't think it > is fair for a contributor to find a committer that has a relevant area of > expertise. A contributor should feel free to ask any committer for a > review, but it should not be mandatory. I would rather have an existing > contributor or committer help with finding a reviewer. > > > > > > On Tue, Jun 6, 2017 at 1:19 PM, Anton Vinogradov < > avinogra...@gridgain.com > > > > > wrote: > > > > > Dmitry, > > > > > > 1) See my initial email, it contains instruction how to find a > reviewer. > > > And it's pretty easy to do when you have something to review (you did > > some > > > code changes). > > > > > > I want to add following to our wiki: > > > > > > " > > > Ask commiter to review changes. > > > Check affected file's git history to find commiter most likely able to > > > review changes. > > > In case it's hard to determine who's able to review by git history use > > > maintainers list presented above. > > > Add "review request" comment to the ticket starting with a commiter > > > username. > > > > > > for example: "[~avinogradov], Please review my changes." > > > > > > Commiter will gain notification and review your changes and/or find > > > another commiter to do this. > > > > > > Important: Each comment should be started with [~username]. > > > " > > > > > > 2) It will be a huge help to the community! > > > > > > On Tue, Jun 6, 2017 at 1:12 PM, Dmitry Pavlov > > > wrote: > > > > > >> Anton, > > >> > > >> > > >> Thank you for explanation. Personal ask instead of group broadcast may > > >> really help. I understand the idea now. > > >> > > >> > > >> One argument against solution way 1) it may be not easy for > contributor, > > >> especially newcomer, to find a right person. > > >> > > >> > > >> What do you think about way 2? Personally, I'm ready to help with > > analysis > > >> and assignment of these 66 tasks from next week. > > >> > > >> > > >> > > >> вт, 6 июн. 2017 г. в 12:57, Anton Vinogradov < > avinogra...@gridgain.com > > >: > > >> > > >> > Dmitry Pavlov, > > >> > > > >> > There is *HUGE *difference between "Devlist, please review my > changes" > > >> > and "Dmitry Pavlov, please review my changes". > > >> > > > >> > In case you're busy right now, you'll, most likely, ignore appeal to > > >> > devlist, but, I'm pretty sure, you'll check appeal to yourself. > > >> > Am I right? > > >> > > > >> > So, my idea is: appeal to devlist is a useless spam maker approach, > > but > > >> > appeal to person(s) works. > > >> > > > >> > On Tue, Jun 6, 2017 at 2:40 AM, Dmitriy Setrakyan < > > >> dsetrak...@apache.org> > > >> > wrote: > > >> > > > >> > > 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 : > > >> > > > > > >> > > > > 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,
Re: "Review workflow" changes to prevent "broken review" issues.
Igniters, Since we found that proposed approach can help, no one mind that I'll add text listed above to the wiki? On Tue, Jun 6, 2017 at 1:19 PM, Anton Vinogradovwrote: > Dmitry, > > 1) See my initial email, it contains instruction how to find a reviewer. > And it's pretty easy to do when you have something to review (you did some > code changes). > > I want to add following to our wiki: > > " > Ask commiter to review changes. > Check affected file's git history to find commiter most likely able to > review changes. > In case it's hard to determine who's able to review by git history use > maintainers list presented above. > Add "review request" comment to the ticket starting with a commiter > username. > > for example: "[~avinogradov], Please review my changes." > > Commiter will gain notification and review your changes and/or find > another commiter to do this. > > Important: Each comment should be started with [~username]. > " > > 2) It will be a huge help to the community! > > On Tue, Jun 6, 2017 at 1:12 PM, Dmitry Pavlov > wrote: > >> Anton, >> >> >> Thank you for explanation. Personal ask instead of group broadcast may >> really help. I understand the idea now. >> >> >> One argument against solution way 1) it may be not easy for contributor, >> especially newcomer, to find a right person. >> >> >> What do you think about way 2? Personally, I'm ready to help with analysis >> and assignment of these 66 tasks from next week. >> >> >> >> вт, 6 июн. 2017 г. в 12:57, Anton Vinogradov : >> >> > Dmitry Pavlov, >> > >> > There is *HUGE *difference between "Devlist, please review my changes" >> > and "Dmitry Pavlov, please review my changes". >> > >> > In case you're busy right now, you'll, most likely, ignore appeal to >> > devlist, but, I'm pretty sure, you'll check appeal to yourself. >> > Am I right? >> > >> > So, my idea is: appeal to devlist is a useless spam maker approach, but >> > appeal to person(s) works. >> > >> > On Tue, Jun 6, 2017 at 2:40 AM, Dmitriy Setrakyan < >> dsetrak...@apache.org> >> > wrote: >> > >> > > 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 > > >> > > 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 : >> > > > >> > > > > 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 >> > 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> >> >
Re: "Review workflow" changes to prevent "broken review" issues.
Dmitry, 1) See my initial email, it contains instruction how to find a reviewer. And it's pretty easy to do when you have something to review (you did some code changes). I want to add following to our wiki: " Ask commiter to review changes. Check affected file's git history to find commiter most likely able to review changes. In case it's hard to determine who's able to review by git history use maintainers list presented above. Add "review request" comment to the ticket starting with a commiter username. for example: "[~avinogradov], Please review my changes." Commiter will gain notification and review your changes and/or find another commiter to do this. Important: Each comment should be started with [~username]. " 2) It will be a huge help to the community! On Tue, Jun 6, 2017 at 1:12 PM, Dmitry Pavlovwrote: > Anton, > > > Thank you for explanation. Personal ask instead of group broadcast may > really help. I understand the idea now. > > > One argument against solution way 1) it may be not easy for contributor, > especially newcomer, to find a right person. > > > What do you think about way 2? Personally, I'm ready to help with analysis > and assignment of these 66 tasks from next week. > > > > вт, 6 июн. 2017 г. в 12:57, Anton Vinogradov : > > > Dmitry Pavlov, > > > > There is *HUGE *difference between "Devlist, please review my changes" > > and "Dmitry Pavlov, please review my changes". > > > > In case you're busy right now, you'll, most likely, ignore appeal to > > devlist, but, I'm pretty sure, you'll check appeal to yourself. > > Am I right? > > > > So, my idea is: appeal to devlist is a useless spam maker approach, but > > appeal to person(s) works. > > > > On Tue, Jun 6, 2017 at 2:40 AM, Dmitriy Setrakyan > > > wrote: > > > > > 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 > > > 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 : > > > > > > > > > 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 > > 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
Re: "Review workflow" changes to prevent "broken review" issues.
Anton, Thank you for explanation. Personal ask instead of group broadcast may really help. I understand the idea now. One argument against solution way 1) it may be not easy for contributor, especially newcomer, to find a right person. What do you think about way 2? Personally, I'm ready to help with analysis and assignment of these 66 tasks from next week. вт, 6 июн. 2017 г. в 12:57, Anton Vinogradov: > Dmitry Pavlov, > > There is *HUGE *difference between "Devlist, please review my changes" > and "Dmitry Pavlov, please review my changes". > > In case you're busy right now, you'll, most likely, ignore appeal to > devlist, but, I'm pretty sure, you'll check appeal to yourself. > Am I right? > > So, my idea is: appeal to devlist is a useless spam maker approach, but > appeal to person(s) works. > > On Tue, Jun 6, 2017 at 2:40 AM, Dmitriy Setrakyan > wrote: > > > 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 > > 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 : > > > > > > > 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 > 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 : > > > > > > > > > > > >> 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
Re: "Review workflow" changes to prevent "broken review" issues.
Dmitry Pavlov, There is *HUGE *difference between "Devlist, please review my changes" and "Dmitry Pavlov, please review my changes". In case you're busy right now, you'll, most likely, ignore appeal to devlist, but, I'm pretty sure, you'll check appeal to yourself. Am I right? So, my idea is: appeal to devlist is a useless spam maker approach, but appeal to person(s) works. On Tue, Jun 6, 2017 at 2:40 AM, Dmitriy Setrakyanwrote: > 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 > 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 : > > > > > 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 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 > > > > 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 : > > > > > > > > > >> 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 > > > >>> > > > > >>> In terms of this model (inspired by Goldratt’s Theory of > > Constraints > > > > >>> (TOC)), I have a question: > > > > >>> Will this
Re: "Review workflow" changes to prevent "broken review" issues.
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 Pavlovwrote: > 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 : > > > 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 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 > > > 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 : > > > > > > > >> 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 > > >>> > > > >>> 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 : > > > >>> > > > Igniters, > > > > > > Currently, according to > > > > > >
Re: "Review workflow" changes to prevent "broken review" issues.
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: > 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 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 > > 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 : > > > > > >> 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 > > >> 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 > >>> > > >>> 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 : > > >>> > > 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 > >
Re: "Review workflow" changes to prevent "broken review" issues.
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 Magdawrote: > 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 > 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 : > > > >> 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 > >> 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 >>> > >>> 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 : > >>> > 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? > > >>> > >> > >
Re: "Review workflow" changes to prevent "broken review" issues.
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 Pavlovwrote: > > 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 : > >> 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 >> 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>> >>> 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 : >>> 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? >>> >>
Re: "Review workflow" changes to prevent "broken review" issues.
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: > 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 > 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 > > > 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 : > > > > > 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? > > > > > >
Re: "Review workflow" changes to prevent "broken review" issues.
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 Pavlovwrote: > 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 > 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 : > > > 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? > > >
Re: "Review workflow" changes to prevent "broken review" issues.
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: > 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? >
Re: "Review workflow" changes to prevent "broken review" issues.
We should keep in mind that contributor do not have to do anything, as this is community. Instead, it is responsibility of the community to make sure that contributions are processed in a timely manner, and that contributors have positive experience with us. So, -1 from my side. On Mon, Jun 5, 2017 at 6:28 PM, Anton Vinogradovwrote: > 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? >