Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ignite.apache.org
MIME-Version: 1.0
In-Reply-To: <B230E837-AFFC-4D56-A03B-10AF177805E4@apache.org>
References: <CAOKDqC-1nxMx0zg3vf4Dcty4SJoP=8bUTENoDe6C6m=5QGkYnA@mail.gmail.com>
 <CALUCNEugF3mUzfUE2ZJpXy4toCoyvb5VMH-7wZ=SQVWV0dZ6CA@mail.gmail.com>
 <CAOKDqC8CAiU27v0BwsFuzMhp0N3X5eYBgPY9Z=OCFU_ZNHrCmQ@mail.gmail.com>
 <CALUCNEuGH0APYt-CUv8ovR2id7-gE+vgsbvBAi3d0S9mTcpeyA@mail.gmail.com> <B230E837-AFFC-4D56-A03B-10AF177805E4@apache.org>
From: Igor Sapego <isapego@gridgain.com>
Date: Mon, 5 Jun 2017 21:06:36 +0300
Message-ID: <CALOGAoyTKcNPDp2O9CjEtxphcZ+=oit_pdRO1aWreNnrCWqVQA@mail.gmail.com>
Subject: Re: "Review workflow" changes to prevent "broken review" issues.
To: dev@ignite.apache.org
Content-Type: multipart/alternative; boundary="94eb2c06384233bac005513a5dbe"
archived-at: Mon, 05 Jun 2017 18:06:49 -0000

--94eb2c06384233bac005513a5dbe
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 <dmagda@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=E2=80=99ll keep an eye on all the in=
coming
> pull-requests shuffling them between committer in the same way proposed i=
n
> 1.
>
> Personally, I=E2=80=99m for 1.
>
> =E2=80=94
> Denis
>
> > On Jun 5, 2017, at 10:28 AM, Dmitry Pavlov <dpavlov.spb@gmail.com>
> wrote:
> >
> > Hi Anton,
> >
> >
> > It is ok for me if it is advice and hint for faster review, as it is no=
w.
> >
> >
> > 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
> >
> > =D0=BF=D0=BD, 5 =D0=B8=D1=8E=D0=BD. 2017 =D0=B3. =D0=B2 20:16, Anton Vi=
nogradov <av@apache.org>:
> >
> >> Vova,
> >>
> >> Contributors interested to make contributions and I propose them to us=
e
> >> *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.spb@gmail.com>
> >> wrote:
> >>
> >>> Hi Igniters, Anton,
> >>>
> >>> Let=E2=80=99s imagine that development process as a chain of producti=
on 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=E2=80=99s Theory of Cons=
traints
> >>> (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, cod=
e
> >>> inspections)
> >>>
> >>> Best Regards,
> >>> Dmitriy Pavlov
> >>>
> >>>
> >>> =D0=BF=D0=BD, 5 =D0=B8=D1=8E=D0=BD. 2017 =D0=B3. =D0=B2 18:28, Anton =
Vinogradov <av@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 fi=
nd
> >>>> 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?
> >>>>
> >>>
> >>
>
>

--94eb2c06384233bac005513a5dbe--