Re: [DISCUSS] Jira state for second reviewer

[Ekaterina Dimitrova]

Hi everyone,

While triaging tickets last week, we realized that the new state works well
with only one caveat. The expectation is Patch Available to be used when
there is no reviewer available and Needs Reviewer to be used when we need a
second reviewer. The name Needs Reviewer might be confusing though and
someone can use it also for first reviewer needed which makes triaging a
bit harder. Benjamin suggested a change of name from Needs Reviewer to
Needs 2nd Reviewer to make its usage more explicit for people. Any thoughts
or objections here?

Best regards,
Ekaterina

On Thu, 8 Jul 2021 at 4:54, Benjamin Lerer  wrote:

> That sounds good to me. Thanks a lot Brandon and Ekaterina for taking care
> of that.
>
> Le mer. 7 juil. 2021 à 23:47, Ekaterina Dimitrova 
> a
> écrit :
>
> > Hey everyone,
> > Considering the latest report of patches which need a reviewer, I think
> > this new Jira state is a great addition.
> > I took it one step further today and asked for it to be available after
> > PATCH AVAILABLE too. This is already implemented. I hope Brandon doesn’t
> > mind my intervention. The reason for that decision was that sometimes we
> > have already first reviewer assigned who is still not working on a review
> > but this shouldn’t stop us to be looking already for a second reviewer.
> >
> > Best regards,
> > Ekaterina
> >
> > On Thu, 1 Jul 2021 at 9:41, Benjamin Lerer  wrote:
> >
> > > +1
> > >
> > > Le jeu. 1 juil. 2021 à 05:58, Caleb Rackliffe <
> calebrackli...@gmail.com>
> > a
> > > écrit :
> > >
> > > > +1
> > > >
> > > > > On Jun 30, 2021, at 4:38 PM, Brandon Williams 
> > > wrote:
> > > > >
> > > > > Hello,
> > > > >
> > > > > Since our project governance requires two committers, which in some
> > > > > circumstances may mean two committers need to review, I'd like to
> add
> > > > > another state to our jira such that finding tickets that need a
> > second
> > > > > reviewer is possible, since it is not currently.
> > > > >
> > > > > On slack, Paulo Motta suggested this:
> > > > >
> > > > > Patch Available -> Review in Progress <-> Needs Reviewer* -> Ready
> To
> > > > Commit
> > > > >
> > > > > Where "needs reviewer" is an optional state that can then move back
> > to
> > > > > "Review in Progress" and carry on.  This would affect all tickets
> in
> > > > > the project, so I'm curious if there are any thoughts or
> objections?
> > > > >
> > > > > Kind Regards,
> > > > > Brandon
> > > > >
> > > > >
> -
> > > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > > > >
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > > >
> > > >
> > >
> >
>

Re: [DISCUSS] Jira state for second reviewer

[Paulo Motta]

+1, agreed this makes its purpose more explicit.

Em seg., 2 de ago. de 2021 às 10:40, Ekaterina Dimitrova <
e.dimitr...@gmail.com> escreveu:

> Hi everyone,
>
> While triaging tickets last week, we realized that the new state works well
> with only one caveat. The expectation is Patch Available to be used when
> there is no reviewer available and Needs Reviewer to be used when we need a
> second reviewer. The name Needs Reviewer might be confusing though and
> someone can use it also for first reviewer needed which makes triaging a
> bit harder. Benjamin suggested a change of name from Needs Reviewer to
> Needs 2nd Reviewer to make its usage more explicit for people. Any thoughts
> or objections here?
>
> Best regards,
> Ekaterina
>
> On Thu, 8 Jul 2021 at 4:54, Benjamin Lerer  wrote:
>
> > That sounds good to me. Thanks a lot Brandon and Ekaterina for taking
> care
> > of that.
> >
> > Le mer. 7 juil. 2021 à 23:47, Ekaterina Dimitrova  >
> > a
> > écrit :
> >
> > > Hey everyone,
> > > Considering the latest report of patches which need a reviewer, I think
> > > this new Jira state is a great addition.
> > > I took it one step further today and asked for it to be available after
> > > PATCH AVAILABLE too. This is already implemented. I hope Brandon
> doesn’t
> > > mind my intervention. The reason for that decision was that sometimes
> we
> > > have already first reviewer assigned who is still not working on a
> review
> > > but this shouldn’t stop us to be looking already for a second reviewer.
> > >
> > > Best regards,
> > > Ekaterina
> > >
> > > On Thu, 1 Jul 2021 at 9:41, Benjamin Lerer  wrote:
> > >
> > > > +1
> > > >
> > > > Le jeu. 1 juil. 2021 à 05:58, Caleb Rackliffe <
> > calebrackli...@gmail.com>
> > > a
> > > > écrit :
> > > >
> > > > > +1
> > > > >
> > > > > > On Jun 30, 2021, at 4:38 PM, Brandon Williams 
> > > > wrote:
> > > > > >
> > > > > > Hello,
> > > > > >
> > > > > > Since our project governance requires two committers, which in
> some
> > > > > > circumstances may mean two committers need to review, I'd like to
> > add
> > > > > > another state to our jira such that finding tickets that need a
> > > second
> > > > > > reviewer is possible, since it is not currently.
> > > > > >
> > > > > > On slack, Paulo Motta suggested this:
> > > > > >
> > > > > > Patch Available -> Review in Progress <-> Needs Reviewer* ->
> Ready
> > To
> > > > > Commit
> > > > > >
> > > > > > Where "needs reviewer" is an optional state that can then move
> back
> > > to
> > > > > > "Review in Progress" and carry on.  This would affect all tickets
> > in
> > > > > > the project, so I'm curious if there are any thoughts or
> > objections?
> > > > > >
> > > > > > Kind Regards,
> > > > > > Brandon
> > > > > >
> > > > > >
> > -
> > > > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > > > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > > > > >
> > > > >
> > > > >
> -
> > > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] Jira state for second reviewer

[Brandon Williams]

+1

On Mon, Aug 2, 2021 at 8:40 AM Ekaterina Dimitrova
 wrote:
>
> Hi everyone,
>
> While triaging tickets last week, we realized that the new state works well
> with only one caveat. The expectation is Patch Available to be used when
> there is no reviewer available and Needs Reviewer to be used when we need a
> second reviewer. The name Needs Reviewer might be confusing though and
> someone can use it also for first reviewer needed which makes triaging a
> bit harder. Benjamin suggested a change of name from Needs Reviewer to
> Needs 2nd Reviewer to make its usage more explicit for people. Any thoughts
> or objections here?
>
> Best regards,
> Ekaterina
>
> On Thu, 8 Jul 2021 at 4:54, Benjamin Lerer  wrote:
>
> > That sounds good to me. Thanks a lot Brandon and Ekaterina for taking care
> > of that.
> >
> > Le mer. 7 juil. 2021 à 23:47, Ekaterina Dimitrova 
> > a
> > écrit :
> >
> > > Hey everyone,
> > > Considering the latest report of patches which need a reviewer, I think
> > > this new Jira state is a great addition.
> > > I took it one step further today and asked for it to be available after
> > > PATCH AVAILABLE too. This is already implemented. I hope Brandon doesn’t
> > > mind my intervention. The reason for that decision was that sometimes we
> > > have already first reviewer assigned who is still not working on a review
> > > but this shouldn’t stop us to be looking already for a second reviewer.
> > >
> > > Best regards,
> > > Ekaterina
> > >
> > > On Thu, 1 Jul 2021 at 9:41, Benjamin Lerer  wrote:
> > >
> > > > +1
> > > >
> > > > Le jeu. 1 juil. 2021 à 05:58, Caleb Rackliffe <
> > calebrackli...@gmail.com>
> > > a
> > > > écrit :
> > > >
> > > > > +1
> > > > >
> > > > > > On Jun 30, 2021, at 4:38 PM, Brandon Williams 
> > > > wrote:
> > > > > >
> > > > > > Hello,
> > > > > >
> > > > > > Since our project governance requires two committers, which in some
> > > > > > circumstances may mean two committers need to review, I'd like to
> > add
> > > > > > another state to our jira such that finding tickets that need a
> > > second
> > > > > > reviewer is possible, since it is not currently.
> > > > > >
> > > > > > On slack, Paulo Motta suggested this:
> > > > > >
> > > > > > Patch Available -> Review in Progress <-> Needs Reviewer* -> Ready
> > To
> > > > > Commit
> > > > > >
> > > > > > Where "needs reviewer" is an optional state that can then move back
> > > to
> > > > > > "Review in Progress" and carry on.  This would affect all tickets
> > in
> > > > > > the project, so I'm curious if there are any thoughts or
> > objections?
> > > > > >
> > > > > > Kind Regards,
> > > > > > Brandon
> > > > > >
> > > > > >
> > -
> > > > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > > > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > > > > >
> > > > >
> > > > > -
> > > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > > > >
> > > > >
> > > >
> > >
> >

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [DISCUSS] Jira state for second reviewer

[bened...@apache.org]

Perhaps “Awaiting Second Review”?

It looks from the flow that this is more accurate, as a second reviewer could 
have been assigned but review could not yet have gotten underway? It’s unclear 
to me what you would do in this case – would it return to Patch Available, or 
sit in Needs Second Reviewer?

From: Brandon Williams 
Date: Monday, 2 August 2021 at 14:57
To: dev@cassandra.apache.org 
Subject: Re: [DISCUSS] Jira state for second reviewer
+1

On Mon, Aug 2, 2021 at 8:40 AM Ekaterina Dimitrova
 wrote:
>
> Hi everyone,
>
> While triaging tickets last week, we realized that the new state works well
> with only one caveat. The expectation is Patch Available to be used when
> there is no reviewer available and Needs Reviewer to be used when we need a
> second reviewer. The name Needs Reviewer might be confusing though and
> someone can use it also for first reviewer needed which makes triaging a
> bit harder. Benjamin suggested a change of name from Needs Reviewer to
> Needs 2nd Reviewer to make its usage more explicit for people. Any thoughts
> or objections here?
>
> Best regards,
> Ekaterina
>
> On Thu, 8 Jul 2021 at 4:54, Benjamin Lerer  wrote:
>
> > That sounds good to me. Thanks a lot Brandon and Ekaterina for taking care
> > of that.
> >
> > Le mer. 7 juil. 2021 à 23:47, Ekaterina Dimitrova 
> > a
> > écrit :
> >
> > > Hey everyone,
> > > Considering the latest report of patches which need a reviewer, I think
> > > this new Jira state is a great addition.
> > > I took it one step further today and asked for it to be available after
> > > PATCH AVAILABLE too. This is already implemented. I hope Brandon doesn’t
> > > mind my intervention. The reason for that decision was that sometimes we
> > > have already first reviewer assigned who is still not working on a review
> > > but this shouldn’t stop us to be looking already for a second reviewer.
> > >
> > > Best regards,
> > > Ekaterina
> > >
> > > On Thu, 1 Jul 2021 at 9:41, Benjamin Lerer  wrote:
> > >
> > > > +1
> > > >
> > > > Le jeu. 1 juil. 2021 à 05:58, Caleb Rackliffe <
> > calebrackli...@gmail.com>
> > > a
> > > > écrit :
> > > >
> > > > > +1
> > > > >
> > > > > > On Jun 30, 2021, at 4:38 PM, Brandon Williams 
> > > > wrote:
> > > > > >
> > > > > > Hello,
> > > > > >
> > > > > > Since our project governance requires two committers, which in some
> > > > > > circumstances may mean two committers need to review, I'd like to
> > add
> > > > > > another state to our jira such that finding tickets that need a
> > > second
> > > > > > reviewer is possible, since it is not currently.
> > > > > >
> > > > > > On slack, Paulo Motta suggested this:
> > > > > >
> > > > > > Patch Available -> Review in Progress <-> Needs Reviewer* -> Ready
> > To
> > > > > Commit
> > > > > >
> > > > > > Where "needs reviewer" is an optional state that can then move back
> > > to
> > > > > > "Review in Progress" and carry on.  This would affect all tickets
> > in
> > > > > > the project, so I'm curious if there are any thoughts or
> > objections?
> > > > > >
> > > > > > Kind Regards,
> > > > > > Brandon
> > > > > >
> > > > > >
> > -
> > > > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > > > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > > > > >
> > > > >
> > > > > -
> > > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > > > >
> > > > >
> > > >
> > >
> >

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [DISCUSS] Jira state for second reviewer

[Paulo Motta]

+1 to "Awaiting Second Review"

Em seg., 2 de ago. de 2021 às 11:02, bened...@apache.org <
bened...@apache.org> escreveu:

> Perhaps “Awaiting Second Review”?
>
> It looks from the flow that this is more accurate, as a second reviewer
> could have been assigned but review could not yet have gotten underway?
> It’s unclear to me what you would do in this case – would it return to
> Patch Available, or sit in Needs Second Reviewer?
>
> From: Brandon Williams 
> Date: Monday, 2 August 2021 at 14:57
> To: dev@cassandra.apache.org 
> Subject: Re: [DISCUSS] Jira state for second reviewer
> +1
>
> On Mon, Aug 2, 2021 at 8:40 AM Ekaterina Dimitrova
>  wrote:
> >
> > Hi everyone,
> >
> > While triaging tickets last week, we realized that the new state works
> well
> > with only one caveat. The expectation is Patch Available to be used when
> > there is no reviewer available and Needs Reviewer to be used when we
> need a
> > second reviewer. The name Needs Reviewer might be confusing though and
> > someone can use it also for first reviewer needed which makes triaging a
> > bit harder. Benjamin suggested a change of name from Needs Reviewer to
> > Needs 2nd Reviewer to make its usage more explicit for people. Any
> thoughts
> > or objections here?
> >
> > Best regards,
> > Ekaterina
> >
> > On Thu, 8 Jul 2021 at 4:54, Benjamin Lerer  wrote:
> >
> > > That sounds good to me. Thanks a lot Brandon and Ekaterina for taking
> care
> > > of that.
> > >
> > > Le mer. 7 juil. 2021 à 23:47, Ekaterina Dimitrova <
> e.dimitr...@gmail.com>
> > > a
> > > écrit :
> > >
> > > > Hey everyone,
> > > > Considering the latest report of patches which need a reviewer, I
> think
> > > > this new Jira state is a great addition.
> > > > I took it one step further today and asked for it to be available
> after
> > > > PATCH AVAILABLE too. This is already implemented. I hope Brandon
> doesn’t
> > > > mind my intervention. The reason for that decision was that
> sometimes we
> > > > have already first reviewer assigned who is still not working on a
> review
> > > > but this shouldn’t stop us to be looking already for a second
> reviewer.
> > > >
> > > > Best regards,
> > > > Ekaterina
> > > >
> > > > On Thu, 1 Jul 2021 at 9:41, Benjamin Lerer 
> wrote:
> > > >
> > > > > +1
> > > > >
> > > > > Le jeu. 1 juil. 2021 à 05:58, Caleb Rackliffe <
> > > calebrackli...@gmail.com>
> > > > a
> > > > > écrit :
> > > > >
> > > > > > +1
> > > > > >
> > > > > > > On Jun 30, 2021, at 4:38 PM, Brandon Williams <
> dri...@gmail.com>
> > > > > wrote:
> > > > > > >
> > > > > > > Hello,
> > > > > > >
> > > > > > > Since our project governance requires two committers, which in
> some
> > > > > > > circumstances may mean two committers need to review, I'd like
> to
> > > add
> > > > > > > another state to our jira such that finding tickets that need a
> > > > second
> > > > > > > reviewer is possible, since it is not currently.
> > > > > > >
> > > > > > > On slack, Paulo Motta suggested this:
> > > > > > >
> > > > > > > Patch Available -> Review in Progress <-> Needs Reviewer* ->
> Ready
> > > To
> > > > > > Commit
> > > > > > >
> > > > > > > Where "needs reviewer" is an optional state that can then move
> back
> > > > to
> > > > > > > "Review in Progress" and carry on.  This would affect all
> tickets
> > > in
> > > > > > > the project, so I'm curious if there are any thoughts or
> > > objections?
> > > > > > >
> > > > > > > Kind Regards,
> > > > > > > Brandon
> > > > > > >
> > > > > > >
> > > -
> > > > > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > > > > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > > > > > >
> > > > > >
> > > > > >
> -
> > > > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > > > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>

Re: [DISCUSS] Jira state for second reviewer

[Ekaterina Dimitrova]

Thank you all.
On Benedict’s question, my understanding is that the idea of Needs Second
Reviewer is to indicate we need to find a second reviewer. I suspect when
we find one he/she will move it to “In review” and provide status updates
in the ticket. I am open for better suggestions.
I guess “Awaiting Second Review” can be added to show that we have
reviewers but the second review is not started yet? I would personally
probably skip adding it and rely that people will follow up on their
assignments. If we incorporate the alerts suggestions that were made some
time ago - I think it would be better after the ticket was in review for
particular amount of time, alert/reminder to be sent to the reviewers. But
probably we can also do both things for more visibility if we as a
community want to.

On Mon, 2 Aug 2021 at 10:02, bened...@apache.org 
wrote:

> Perhaps “Awaiting Second Review”?
>
> It looks from the flow that this is more accurate, as a second reviewer
> could have been assigned but review could not yet have gotten underway?
> It’s unclear to me what you would do in this case – would it return to
> Patch Available, or sit in Needs Second Reviewer?
>
> From: Brandon Williams 
> Date: Monday, 2 August 2021 at 14:57
> To: dev@cassandra.apache.org 
> Subject: Re: [DISCUSS] Jira state for second reviewer
> +1
>
> On Mon, Aug 2, 2021 at 8:40 AM Ekaterina Dimitrova
>  wrote:
> >
> > Hi everyone,
> >
> > While triaging tickets last week, we realized that the new state works
> well
> > with only one caveat. The expectation is Patch Available to be used when
> > there is no reviewer available and Needs Reviewer to be used when we
> need a
> > second reviewer. The name Needs Reviewer might be confusing though and
> > someone can use it also for first reviewer needed which makes triaging a
> > bit harder. Benjamin suggested a change of name from Needs Reviewer to
> > Needs 2nd Reviewer to make its usage more explicit for people. Any
> thoughts
> > or objections here?
> >
> > Best regards,
> > Ekaterina
> >
> > On Thu, 8 Jul 2021 at 4:54, Benjamin Lerer  wrote:
> >
> > > That sounds good to me. Thanks a lot Brandon and Ekaterina for taking
> care
> > > of that.
> > >
> > > Le mer. 7 juil. 2021 à 23:47, Ekaterina Dimitrova <
> e.dimitr...@gmail.com>
> > > a
> > > écrit :
> > >
> > > > Hey everyone,
> > > > Considering the latest report of patches which need a reviewer, I
> think
> > > > this new Jira state is a great addition.
> > > > I took it one step further today and asked for it to be available
> after
> > > > PATCH AVAILABLE too. This is already implemented. I hope Brandon
> doesn’t
> > > > mind my intervention. The reason for that decision was that
> sometimes we
> > > > have already first reviewer assigned who is still not working on a
> review
> > > > but this shouldn’t stop us to be looking already for a second
> reviewer.
> > > >
> > > > Best regards,
> > > > Ekaterina
> > > >
> > > > On Thu, 1 Jul 2021 at 9:41, Benjamin Lerer 
> wrote:
> > > >
> > > > > +1
> > > > >
> > > > > Le jeu. 1 juil. 2021 à 05:58, Caleb Rackliffe <
> > > calebrackli...@gmail.com>
> > > > a
> > > > > écrit :
> > > > >
> > > > > > +1
> > > > > >
> > > > > > > On Jun 30, 2021, at 4:38 PM, Brandon Williams <
> dri...@gmail.com>
> > > > > wrote:
> > > > > > >
> > > > > > > Hello,
> > > > > > >
> > > > > > > Since our project governance requires two committers, which in
> some
> > > > > > > circumstances may mean two committers need to review, I'd like
> to
> > > add
> > > > > > > another state to our jira such that finding tickets that need a
> > > > second
> > > > > > > reviewer is possible, since it is not currently.
> > > > > > >
> > > > > > > On slack, Paulo Motta suggested this:
> > > > > > >
> > > > > > > Patch Available -> Review in Progress <-> Needs Reviewer* ->
> Ready
> > > To
> > > > > > Commit
> > > > > > >
> > > > > > > Where "needs reviewer" is an optional state that can then move
> back
> > > > to
> > > > > > > "Review in Progress" and carry on.  This would affect all
> tickets
> > > in
> > > > > > > the project, so I'm curious if there are any thoughts or
> > > objections?
> > > > > > >
> > > > > > > Kind Regards,
> > > > > > > Brandon
> > > > > > >
> > > > > > >
> > > -
> > > > > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > > > > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > > > > > >
> > > > > >
> > > > > >
> -
> > > > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > > > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>

Re: [DISCUSS] Jira state for second reviewer

[bened...@apache.org]

I was proposing substituting “Needs Second Reviewer” for “Awaiting Second 
Review” as this encapsulates the need for an additional reviewer _and_ the 
pending status for the review beginning.

I don’t think it is reasonable to assume that once a reviewer is found that 
they will move it into “In Review” nor would that be very helpful, as we would 
not know which tickets were actively under review as opposed to pending review 
by an agreed second reviewer.

From: Ekaterina Dimitrova 
Date: Monday, 2 August 2021 at 15:15
To: dev@cassandra.apache.org 
Subject: Re: [DISCUSS] Jira state for second reviewer
Thank you all.
On Benedict’s question, my understanding is that the idea of Needs Second
Reviewer is to indicate we need to find a second reviewer. I suspect when
we find one he/she will move it to “In review” and provide status updates
in the ticket. I am open for better suggestions.
I guess “Awaiting Second Review” can be added to show that we have
reviewers but the second review is not started yet? I would personally
probably skip adding it and rely that people will follow up on their
assignments. If we incorporate the alerts suggestions that were made some
time ago - I think it would be better after the ticket was in review for
particular amount of time, alert/reminder to be sent to the reviewers. But
probably we can also do both things for more visibility if we as a
community want to.

On Mon, 2 Aug 2021 at 10:02, bened...@apache.org 
wrote:

> Perhaps “Awaiting Second Review”?
>
> It looks from the flow that this is more accurate, as a second reviewer
> could have been assigned but review could not yet have gotten underway?
> It’s unclear to me what you would do in this case – would it return to
> Patch Available, or sit in Needs Second Reviewer?
>
> From: Brandon Williams 
> Date: Monday, 2 August 2021 at 14:57
> To: dev@cassandra.apache.org 
> Subject: Re: [DISCUSS] Jira state for second reviewer
> +1
>
> On Mon, Aug 2, 2021 at 8:40 AM Ekaterina Dimitrova
>  wrote:
> >
> > Hi everyone,
> >
> > While triaging tickets last week, we realized that the new state works
> well
> > with only one caveat. The expectation is Patch Available to be used when
> > there is no reviewer available and Needs Reviewer to be used when we
> need a
> > second reviewer. The name Needs Reviewer might be confusing though and
> > someone can use it also for first reviewer needed which makes triaging a
> > bit harder. Benjamin suggested a change of name from Needs Reviewer to
> > Needs 2nd Reviewer to make its usage more explicit for people. Any
> thoughts
> > or objections here?
> >
> > Best regards,
> > Ekaterina
> >
> > On Thu, 8 Jul 2021 at 4:54, Benjamin Lerer  wrote:
> >
> > > That sounds good to me. Thanks a lot Brandon and Ekaterina for taking
> care
> > > of that.
> > >
> > > Le mer. 7 juil. 2021 à 23:47, Ekaterina Dimitrova <
> e.dimitr...@gmail.com>
> > > a
> > > écrit :
> > >
> > > > Hey everyone,
> > > > Considering the latest report of patches which need a reviewer, I
> think
> > > > this new Jira state is a great addition.
> > > > I took it one step further today and asked for it to be available
> after
> > > > PATCH AVAILABLE too. This is already implemented. I hope Brandon
> doesn’t
> > > > mind my intervention. The reason for that decision was that
> sometimes we
> > > > have already first reviewer assigned who is still not working on a
> review
> > > > but this shouldn’t stop us to be looking already for a second
> reviewer.
> > > >
> > > > Best regards,
> > > > Ekaterina
> > > >
> > > > On Thu, 1 Jul 2021 at 9:41, Benjamin Lerer 
> wrote:
> > > >
> > > > > +1
> > > > >
> > > > > Le jeu. 1 juil. 2021 à 05:58, Caleb Rackliffe <
> > > calebrackli...@gmail.com>
> > > > a
> > > > > écrit :
> > > > >
> > > > > > +1
> > > > > >
> > > > > > > On Jun 30, 2021, at 4:38 PM, Brandon Williams <
> dri...@gmail.com>
> > > > > wrote:
> > > > > > >
> > > > > > > Hello,
> > > > > > >
> > > > > > > Since our project governance requires two committers, which in
> some
> > > > > > > circumstances may mean two committers need to review, I'd like
> to
> > > add
> > > > > > > another state to our jira such that finding tickets that need a
> > > > second
> > > > > > > reviewer is possible, since it is not currently.
> > > > > > >
> > > > > > > On slack, Paulo Motta suggested this:
> > > > > > >
> > > > > > > Patch Available -> Review in Progress <-> Needs Reviewer* ->
> Ready
> > > To
> > > > > > Commit
> > > > > > >
> > > > > > > Where "needs reviewer" is an optional state that can then move
> back
> > > > to
> > > > > > > "Review in Progress" and carry on.  This would affect all
> tickets
> > > in
> > > > > > > the project, so I'm curious if there are any thoughts or
> > > objections?
> > > > > > >
> > > > > > > Kind Regards,
> > > > > > > Brandon
> > > > > > >
> > > > > > >
> > > -
> > > > > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > >

Re: [DISCUSS] Jira state for second reviewer

[Ekaterina Dimitrova]

My only worry is that If we incorporate both things in one state this means
that people won’t be able to find immediately tickets to assign for review.
They will have to go and check whether it needs a reviewer or just the
second reviewer haven’t started review yet. That is why I suggested then to
have both “Needs Second Reviewer” and “Awaiting Second Review” as indeed,
we can’t expect that people will immediately start a review when they
assign themselves as a reviewer. That I totally agree with. My only point
is that we need a state that incorporates really only one state - “we need
a person to help with review” and no other meaning. Otherwise triaging will
be again harder. IMHO this will help us to produce good reports and easily
identify spots that need attention/help.
I don’t disagree with you, I just think this is one additional point we
have to consider separately.

On Mon, 2 Aug 2021 at 10:17, bened...@apache.org 
wrote:

> I was proposing substituting “Needs Second Reviewer” for “Awaiting Second
> Review” as this encapsulates the need for an additional reviewer _and_ the
> pending status for the review beginning.
>
> I don’t think it is reasonable to assume that once a reviewer is found
> that they will move it into “In Review” nor would that be very helpful, as
> we would not know which tickets were actively under review as opposed to
> pending review by an agreed second reviewer.
>
> From: Ekaterina Dimitrova 
> Date: Monday, 2 August 2021 at 15:15
> To: dev@cassandra.apache.org 
> Subject: Re: [DISCUSS] Jira state for second reviewer
> Thank you all.
> On Benedict’s question, my understanding is that the idea of Needs Second
> Reviewer is to indicate we need to find a second reviewer. I suspect when
> we find one he/she will move it to “In review” and provide status updates
> in the ticket. I am open for better suggestions.
> I guess “Awaiting Second Review” can be added to show that we have
> reviewers but the second review is not started yet? I would personally
> probably skip adding it and rely that people will follow up on their
> assignments. If we incorporate the alerts suggestions that were made some
> time ago - I think it would be better after the ticket was in review for
> particular amount of time, alert/reminder to be sent to the reviewers. But
> probably we can also do both things for more visibility if we as a
> community want to.
>
> On Mon, 2 Aug 2021 at 10:02, bened...@apache.org 
> wrote:
>
> > Perhaps “Awaiting Second Review”?
> >
> > It looks from the flow that this is more accurate, as a second reviewer
> > could have been assigned but review could not yet have gotten underway?
> > It’s unclear to me what you would do in this case – would it return to
> > Patch Available, or sit in Needs Second Reviewer?
> >
> > From: Brandon Williams 
> > Date: Monday, 2 August 2021 at 14:57
> > To: dev@cassandra.apache.org 
> > Subject: Re: [DISCUSS] Jira state for second reviewer
> > +1
> >
> > On Mon, Aug 2, 2021 at 8:40 AM Ekaterina Dimitrova
> >  wrote:
> > >
> > > Hi everyone,
> > >
> > > While triaging tickets last week, we realized that the new state works
> > well
> > > with only one caveat. The expectation is Patch Available to be used
> when
> > > there is no reviewer available and Needs Reviewer to be used when we
> > need a
> > > second reviewer. The name Needs Reviewer might be confusing though and
> > > someone can use it also for first reviewer needed which makes triaging
> a
> > > bit harder. Benjamin suggested a change of name from Needs Reviewer to
> > > Needs 2nd Reviewer to make its usage more explicit for people. Any
> > thoughts
> > > or objections here?
> > >
> > > Best regards,
> > > Ekaterina
> > >
> > > On Thu, 8 Jul 2021 at 4:54, Benjamin Lerer  wrote:
> > >
> > > > That sounds good to me. Thanks a lot Brandon and Ekaterina for taking
> > care
> > > > of that.
> > > >
> > > > Le mer. 7 juil. 2021 à 23:47, Ekaterina Dimitrova <
> > e.dimitr...@gmail.com>
> > > > a
> > > > écrit :
> > > >
> > > > > Hey everyone,
> > > > > Considering the latest report of patches which need a reviewer, I
> > think
> > > > > this new Jira state is a great addition.
> > > > > I took it one step further today and asked for it to be available
> > after
> > > > > PATCH AVAILABLE too. This is already implemented. I hope Brandon
> > doesn’t
> > > > > mind my intervention. The reason for that decision was that
> > sometimes we
> > > > > have already first reviewer assigned who is still not working on a
> > review
> > > > > but this shouldn’t stop us to be looking already for a second
> > reviewer.
> > > > >
> > > > > Best regards,
> > > > > Ekaterina
> > > > >
> > > > > On Thu, 1 Jul 2021 at 9:41, Benjamin Lerer 
> > wrote:
> > > > >
> > > > > > +1
> > > > > >
> > > > > > Le jeu. 1 juil. 2021 à 05:58, Caleb Rackliffe <
> > > > calebrackli...@gmail.com>
> > > > > a
> > > > > > écrit :
> > > > > >
> > > > > > > +1
> > > > > > >
> > > > > > > > On Jun 30, 2021, at 4:38 PM, Brandon Williams <

Re: [DISCUSS] Jira state for second reviewer

[bened...@apache.org]

So, I don’t feel strongly about this at all, I just think it will be more 
confusing this way so lead to more inconsistency of usage, as it will be 
unclear what this second reviewer should do if they don’t start reviewing 
immediately, so some tickets will remain in “Needs Second Reviewer” when it 
doesn’t, and others will be in “In Review” when it isn’t.

It will also be more burdensome to find out the true state of a ticket: if the 
new reviewer transitions a ticket to “In Review” but doesn’t in fact start 
review, you now need to ask a human being if they’re really reviewing something 
or not, there’s no way to find out by yourself. If the “Awaiting Second Review” 
state is interpreted as perhaps only needing a second reviewer, a report can 
easily distinguish this by listing the contents of the Reviewers column.

But, I don’t anticipate losing any sleep over whatever we decide here.

From: Ekaterina Dimitrova 
Date: Monday, 2 August 2021 at 15:37
To: dev@cassandra.apache.org 
Subject: Re: [DISCUSS] Jira state for second reviewer
My only worry is that If we incorporate both things in one state this means
that people won’t be able to find immediately tickets to assign for review.
They will have to go and check whether it needs a reviewer or just the
second reviewer haven’t started review yet. That is why I suggested then to
have both “Needs Second Reviewer” and “Awaiting Second Review” as indeed,
we can’t expect that people will immediately start a review when they
assign themselves as a reviewer. That I totally agree with. My only point
is that we need a state that incorporates really only one state - “we need
a person to help with review” and no other meaning. Otherwise triaging will
be again harder. IMHO this will help us to produce good reports and easily
identify spots that need attention/help.
I don’t disagree with you, I just think this is one additional point we
have to consider separately.

On Mon, 2 Aug 2021 at 10:17, bened...@apache.org 
wrote:

> I was proposing substituting “Needs Second Reviewer” for “Awaiting Second
> Review” as this encapsulates the need for an additional reviewer _and_ the
> pending status for the review beginning.
>
> I don’t think it is reasonable to assume that once a reviewer is found
> that they will move it into “In Review” nor would that be very helpful, as
> we would not know which tickets were actively under review as opposed to
> pending review by an agreed second reviewer.
>
> From: Ekaterina Dimitrova 
> Date: Monday, 2 August 2021 at 15:15
> To: dev@cassandra.apache.org 
> Subject: Re: [DISCUSS] Jira state for second reviewer
> Thank you all.
> On Benedict’s question, my understanding is that the idea of Needs Second
> Reviewer is to indicate we need to find a second reviewer. I suspect when
> we find one he/she will move it to “In review” and provide status updates
> in the ticket. I am open for better suggestions.
> I guess “Awaiting Second Review” can be added to show that we have
> reviewers but the second review is not started yet? I would personally
> probably skip adding it and rely that people will follow up on their
> assignments. If we incorporate the alerts suggestions that were made some
> time ago - I think it would be better after the ticket was in review for
> particular amount of time, alert/reminder to be sent to the reviewers. But
> probably we can also do both things for more visibility if we as a
> community want to.
>
> On Mon, 2 Aug 2021 at 10:02, bened...@apache.org 
> wrote:
>
> > Perhaps “Awaiting Second Review”?
> >
> > It looks from the flow that this is more accurate, as a second reviewer
> > could have been assigned but review could not yet have gotten underway?
> > It’s unclear to me what you would do in this case – would it return to
> > Patch Available, or sit in Needs Second Reviewer?
> >
> > From: Brandon Williams 
> > Date: Monday, 2 August 2021 at 14:57
> > To: dev@cassandra.apache.org 
> > Subject: Re: [DISCUSS] Jira state for second reviewer
> > +1
> >
> > On Mon, Aug 2, 2021 at 8:40 AM Ekaterina Dimitrova
> >  wrote:
> > >
> > > Hi everyone,
> > >
> > > While triaging tickets last week, we realized that the new state works
> > well
> > > with only one caveat. The expectation is Patch Available to be used
> when
> > > there is no reviewer available and Needs Reviewer to be used when we
> > need a
> > > second reviewer. The name Needs Reviewer might be confusing though and
> > > someone can use it also for first reviewer needed which makes triaging
> a
> > > bit harder. Benjamin suggested a change of name from Needs Reviewer to
> > > Needs 2nd Reviewer to make its usage more explicit for people. Any
> > thoughts
> > > or objections here?
> > >
> > > Best regards,
> > > Ekaterina
> > >
> > > On Thu, 8 Jul 2021 at 4:54, Benjamin Lerer  wrote:
> > >
> > > > That sounds good to me. Thanks a lot Brandon and Ekaterina for taking
> > care
> > > > of that.
> > > >
> > > > Le mer. 7 juil. 2021 à 23:47, Ekaterina Dimitrova <
> > e

Cassandra Dev Project status: 2021-08-02

[Joshua McKenzie]

Hello Cassandra Project!

As we all know, Cassandra 4.0.0 went GA on July 26th. This is a huge
milestone for the project and the product of the efforts of hundreds of
people; thank you and congratulations to everyone for the hard work and
dedication to the project!

As we used to send out biweekly emails in the run up to 4.0, a few of us
figured we could keep this up to help provide some context and jumping off
points for people who want to get involved in the project or stay up to
date with what's going on.

We have a new release tracking kanban board available here:
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=484. These
things are incredibly configurable; if you have any feedback, think
anything's missing, would like more quick filters, just hit me up on the
ASF slack (@jmckenzie) and I'll add things in.

-
Some interesting views:

[Starter Tickets]
For those just getting started with the project, there's a "Starter
Tickets" quick label that corresponds to our Low Hanging Fruit status. Any
of these tickets should be of an appropriate complexity for someone new to
the project to take them on:
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=484&quickFilter=2162&quickFilter=2160

[Needs Reviewers]
We have 5 tickets that are Patch Available and missing reviewers, and 3 In
Progress missing reviewers
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=484&quickFilter=2161

[Committer Attention]
We as a project have agreed that any ticket that is committed should be
worked on by 2 committers, be it 2 reviewers or 1 assignee and 1 reviewer.
There's a column in the kanban board that corresponds with the "Needs
Reviewer" status. We currently have one ticket, CASSANDRA-14160 -
"maxPurgeableTimestamp should traverse tables in order of minTimestamp",
that needs a 2nd committer to review along with Marcus.
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=484&quickFilter=2170

-
[CEPs]
For those new to the project, we've adopted a similar process for major
features to some other Apache projects in the form of CEPs, or "Cassandra
Enhancement Proposals". See:
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652201

We currently have 6 CEPs under discussion with another 5 in draft. There's
been some good conversation on the mailing list about a few of the CEPs -
please chime in if you have a point of view on the proposed features.
Link to pony mail search of CEP discussions:
https://lists.apache.org/list.html?dev@cassandra.apache.org:lte=1M:CEP

CEP-10 was voted on and received approval from the community to continue
forward.
On CEP-11, there's been some discussion about the architectural proximity
of the memtable and commitlog implementation. More input is always welcome.
https://lists.apache.org/thread.html/rb5e950f882196764744c31bc3c13dfbf0603cb9f8bc2f6cfb976d285%40%3Cdev.cassandra.apache.org%3E

-
[Release Cadence]
We had a conversation on the ML earlier this year about what we wanted to
do in terms of support timelines and release cadence. The pony mail link
can be found here:
https://lists.apache.org/thread.html/re15543b55e5d01245ad75f7ec35af97e9895d37c01562eab31963dd4%40%3Cdev.cassandra.apache.org%3E

The conclusions on that thread:

> For the release cadence the agreement is:* one release every year +
> periodic trunk snapshot*



> * 4.0: Fully supported until April 2023 and high severity bugs until April
> 2024 (2 year full, 1 year bugfix)
> * 3.11: Fully supported until April 2022 and high severity bugs until
> April 2023 (1 year full, 1 year bugfix)
> * 3.0: Supported for high severity correctness/performance bugs until
> April 2022 (1 year bugfix)
> * 2.2+2.1: EOL immediately.
> Then going forward we could have this nice pattern when we cut the yearly
> release:
> Y(n-0): Support for 3 years from now (2 full, 1 bugfix)
> Y(n-1): Fully supported for 1 more year and supported for high severity
> correctness/perf bugs 1 year after that (1 full, 1 bugfix)
> Y(n-2): Supported for high severity correctness/bugs for 1 more year (1
> bugfix)


2 things of note: the dates on the site say things are supported until
April 2022 and likely need to be revised to match t+12 for our 4.0 GA date,
and we also list support on the site on 2.2 until April 2022 whereas we
discussed it being EOL on the ML. We'll clarify that on the other
discussion thread.

As always, thanks everyone for everything you do on the project. There is
no Cassandra without this community; thank you!

~Josh

Re: [DISCUSS] Releases after 4.0

[Joshua McKenzie]

Where did we land on this? Joey's statement above:

> * 4.0: Fully supported until April 2023 and high severity bugs until April
> 2024 (2 year full, 1 year bugfix)
> * 3.11: Fully supported until April 2022 and high severity bugs until
> April 2023 (1 year full, 1 year bugfix)
> * 3.0: Supported for high severity correctness/performance bugs until
> April 2022 (1 year bugfix)
> * 2.2+2.1: EOL immediately.
> Then going forward we could have this nice pattern when we cut the yearly
> release:
> Y(n-0): Support for 3 years from now (2 full, 1 bugfix)
> Y(n-1): Fully supported for 1 more year and supported for high severity
> correctness/perf bugs 1 year after that (1 full, 1 bugfix)
> Y(n-2): Supported for high severity correctness/bugs for 1 more year (1
> bugfix)


Doesn't look like it matches what we have on the site:
 https://cassandra.apache.org/_/download.html

Apache Cassandra 2.2
> Released on 2020-11-04, and supported until 4.1 release (April 2022) with
> critical fixes only.


Also - do we need to revise our dates from April 2022 to July 2022 to
reflect when GA hit?



On Thu, Apr 1, 2021 at 10:06 AM Ekaterina Dimitrova 
wrote:

> +1 on my end about the Roadmap page and to start looking in the future
> again :-) I am also optimistic about the assumption of having 4.0 out in
> April :-) Exciting times
>
> On Thu, 1 Apr 2021 at 9:37, Benedict Elliott Smith 
> wrote:
>
> > > it would make sense to put that information on a *Roadmap* page
> >
> > That makes sense to me, and I'm looking forward to agreeing a roadmap. I
> > think it will be nice for the project to start properly looking to the
> > future again.
> >
> > On 01/04/2021, 14:06, "Benjamin Lerer" 
> > wrote:
> >
> > Thanks everybody.
> >
> > I opened CASSANDRA-16556
> >  to update
> the
> > end
> > of support dates for the different versions. I assumed that we will
> > manage
> > to release 4.0-GA in April (otherwise I will re-update them ;-) )
> >
> > Concerning the release cadence, it seems that we do not have a proper
> > place
> > to put that information on our website. In an offline discussion Mick
> > raised the point that it would make sense to put that information on
> a
> > *Roadmap
> > *page. That makes sense to me. I will trigger the roadmap discussion
> > next
> > week and once we agree on some roadmap, I propose to create a new
> page
> > for
> > it where I will include the information on the release cadence.
> >
> > I am fully open to another proposal.
> >
> >
> > On Tue, Mar 30, 2021 at 11:24 AM Sam Tunnicliffe 
> > wrote:
> >
> > > +1
> > >
> > > > On 29 Mar 2021, at 15:41, Joseph Lynch 
> > wrote:
> > > >
> > > > I am slightly concerned about removing support for critical bug
> > fixes
> > > > in 3.0 on a short time-frame (<1 year). I know of at least a few
> > major
> > > > installations, including ours, who are just now able to finish
> > > > upgrades to 3.0 in production due to the number of correctness
> and
> > > > performance bugs introduced in that release which have only been
> > > > debugged and fixed in the past ~2 years.
> > > >
> > > > I like the idea of the 3-year support cycles, but I think since
> > > > 3.0/3.11/4.0 took so long to stabilize to a point folks could
> > upgrade
> > > > to, we should reset the clock somewhat. What about the following
> > > > assuming an April 2021 4.0 cut:
> > > >
> > > > 4.0: Fully supported until April 2023 and high severity bugs
> until
> > > > April 2024 (2 year full, 1 year bugfix)
> > > > 3.11: Fully supported until April 2022 and high severity bugs
> until
> > > > April 2023 (1 year full, 1 year bugfix).
> > > > 3.0: Supported for high severity correctness/performance bugs
> until
> > > > April 2022 (1 year bugfix)
> > > > 2.2+2.1: EOL immediately.
> > > >
> > > > Then going forward we could have this nice pattern when we cut
> the
> > > > yearly release:
> > > > Y(n-0): Support for 3 years from now (2 full, 1 bugfix)
> > > > Y(n-1): Fully supported for 1 more year and supported for high
> > > > severity correctness/perf bugs 1 year after that (1 full, 1
> bugfix)
> > > > Y(n-2): Supported for high severity correctness/bugs for 1 more
> > year (1
> > > bugfix)
> > > >
> > > > What do you think?
> > > > -Joey
> > > >
> > > > On Mon, Mar 29, 2021 at 9:39 AM Benjamin Lerer
> > > >  wrote:
> > > >>
> > > >> Thanks to everybody and sorry for not finalizing that email
> thread
> > > sooner.
> > > >>
> > > >> For the release cadence the agreement is:* one release every
> year
> > +
> > > >> periodic trunc snapshot*
> > > >> For the number of releases being supported the agreement is 3.
> > *Every
> > > >> incoming release should be supported for 3 years.*
> > > >>
> > > >> We did not reach a

Re: [DISCUSS] Jira state for second reviewer

[Ekaterina Dimitrova]

In the meantime the new Kanban board filter for  Needs Reviewer is called
Committer Needed which made me think that this may be probably an even
better option here based on the states meanings I outlined for myself:

PATCH AVAILABLE - we have a patch; No reviewer has started working on
review - neither committer, nor non-committer. We have a lonely
non-committer patch waiting for committers’ attention.
IN REVIEW - we already satisfy the 2 committers reviews requirement and
they are both “in progress reviews”. NOTE: We rely on the committers to
follow up with non-committers who might be also reviewing whether the patch
can already be committed or not; after the two committers required have
approved the patch.
COMMITTER NEEDED:
- 1st option - we need only one committer to join the review effort in
order to satisfy the requirement of two committers’ approval in order to
commit a patch.
- 2nd option - we are waiting for a second committer’s review to start or
even both committers’ reviews to start. It doesn't matter which reviewer
was assigned first or second or who starts when, we don’t have the two
needed committers’ reviews started yet.

Does this make more sense?
Do I miss any cases or misunderstood anything?

On Mon, 2 Aug 2021 at 10:45, bened...@apache.org 
wrote:

> So, I don’t feel strongly about this at all, I just think it will be more
> confusing this way so lead to more inconsistency of usage, as it will be
> unclear what this second reviewer should do if they don’t start reviewing
> immediately, so some tickets will remain in “Needs Second Reviewer” when it
> doesn’t, and others will be in “In Review” when it isn’t.
>
> It will also be more burdensome to find out the true state of a ticket: if
> the new reviewer transitions a ticket to “In Review” but doesn’t in fact
> start review, you now need to ask a human being if they’re really reviewing
> something or not, there’s no way to find out by yourself. If the “Awaiting
> Second Review” state is interpreted as perhaps only needing a second
> reviewer, a report can easily distinguish this by listing the contents of
> the Reviewers column.
>
> But, I don’t anticipate losing any sleep over whatever we decide here.
>
> From: Ekaterina Dimitrova 
> Date: Monday, 2 August 2021 at 15:37
> To: dev@cassandra.apache.org 
> Subject: Re: [DISCUSS] Jira state for second reviewer
> My only worry is that If we incorporate both things in one state this means
> that people won’t be able to find immediately tickets to assign for review.
> They will have to go and check whether it needs a reviewer or just the
> second reviewer haven’t started review yet. That is why I suggested then to
> have both “Needs Second Reviewer” and “Awaiting Second Review” as indeed,
> we can’t expect that people will immediately start a review when they
> assign themselves as a reviewer. That I totally agree with. My only point
> is that we need a state that incorporates really only one state - “we need
> a person to help with review” and no other meaning. Otherwise triaging will
> be again harder. IMHO this will help us to produce good reports and easily
> identify spots that need attention/help.
> I don’t disagree with you, I just think this is one additional point we
> have to consider separately.
>
> On Mon, 2 Aug 2021 at 10:17, bened...@apache.org 
> wrote:
>
> > I was proposing substituting “Needs Second Reviewer” for “Awaiting Second
> > Review” as this encapsulates the need for an additional reviewer _and_
> the
> > pending status for the review beginning.
> >
> > I don’t think it is reasonable to assume that once a reviewer is found
> > that they will move it into “In Review” nor would that be very helpful,
> as
> > we would not know which tickets were actively under review as opposed to
> > pending review by an agreed second reviewer.
> >
> > From: Ekaterina Dimitrova 
> > Date: Monday, 2 August 2021 at 15:15
> > To: dev@cassandra.apache.org 
> > Subject: Re: [DISCUSS] Jira state for second reviewer
> > Thank you all.
> > On Benedict’s question, my understanding is that the idea of Needs Second
> > Reviewer is to indicate we need to find a second reviewer. I suspect when
> > we find one he/she will move it to “In review” and provide status updates
> > in the ticket. I am open for better suggestions.
> > I guess “Awaiting Second Review” can be added to show that we have
> > reviewers but the second review is not started yet? I would personally
> > probably skip adding it and rely that people will follow up on their
> > assignments. If we incorporate the alerts suggestions that were made some
> > time ago - I think it would be better after the ticket was in review for
> > particular amount of time, alert/reminder to be sent to the reviewers.
> But
> > probably we can also do both things for more visibility if we as a
> > community want to.
> >
> > On Mon, 2 Aug 2021 at 10:02, bened...@apache.org 
> > wrote:
> >
> > > Perhaps “Awaiting Second Review”?
> > >
> > > It looks from the f