Usage of Assignee

[Patrick Hiesel]

Hi Sven and Gustaf,

I remember you implemented the assignee feature in Gerrit and wanted to cycle back to see how it is used at Axis (and potentially in other installations).

We recently got some feedback that users found this confusing because the distinction between a reviewer and an assignee was not clear to them.

We see usages in our installation where people use the field to pass around a change between the owner (needs to adapt code) and a single reviewer (needs to review). Do you see other usages? Is this feature widely used?

I am asking because with more insight into usage, we might be able to improve the UX a bit.

Thanks,

Patrick

[Gustaf Lundh]

Hi Patrick,

I'll do my best to reiterate the reasoning behind the "Assignee"-feature. We presented the same arguments during a presentation at the Hackathon where the assignee future was implemented.

Our company (and other companies we had this discussion with) sometimes suffered from lack of clear accountability when it came to carry out reviews on some changes. Especially changes with lots of reviewers added could get stuck for ages. It seemed that these all these reviewers counted on someone else to step up and carry out the actual review. Without clear assigned responsibility of whom should to step up to ensure that the change actually got closer to integration we would see unnecessary long lead times.

By assigning one of the reviewers as an "Assignee", that person had the ultimate responsibility to ensure that the change did not get stuck in review limbo. If the appointed Assignee could not review the change for whatever reason, the responsibility of the Assignee was to appoint someone else to actually carry out the review. This way, there would always be someone with full accountability. With that accountability there could be no excuses. If a new revision is expected from the change owner, the change owner could be given the role of "Assignee".

The concept of an assignee is well established in ticket systems and we argued that with out a clear "Assignee" in these ticket systems, most of them would be far less effective.

In our team the feature is used as intended. Far from all changes have an Assignee, but changes that needs to move through the process quickly will have a someone assigned to the Change. From my own observation this works really well. Changes that has someone assigned to them gets feedback _a lot_ quicker than changes without one. Clear accountability works.

I think adding someone as a reviewer can be seen as a request (it is called a "review request" after all). Setting an Assignee should be seen as an action point. 

Through extensions you could tweak the workflow to ensure that one maintainer does not gets assigned far too many changes (which would be indicative of a bottleneck). We also discussed writing a plugin that would assign one of the project owners to the change if it was unreviewed for a certain time, though it is not something we have actually tried.

What is described here is our reasoning for implementing the "Assignee"-feature and how we intended the workflow to work. Though I'm sure that many teams tweak the meaning of "Assignee" to fit their workflows. For instance I know that some teams iterate a change within a team for a while and when it is time to integrate the change, the code base owner would get assigned to it and would know that this particular change needs attention. This is good for prioritization, since some code base owners have _a lot_ of changes on their dashboard.  

If you have any ideas about the UX I would love to hear them. For us, I think the feature works pretty well.

/Gustaf

---

From: Patrick Hiesel <hie...@google.com>
Sent: Wednesday, November 7, 2018 5:07 PM
To: Sven Selberg; Gustaf Lundh
Cc: repo-d...@googlegroups.com
Subject: Usage of Assignee

 

[David Pursehouse]

On Thu, Nov 8, 2018 at 6:09 AM Gustaf Lundh <gustaf...@axis.com> wrote:

Hi Patrick,

I'll do my best to reiterate the reasoning behind the "Assignee"-feature. We presented the same arguments during a presentation at the Hackathon where the assignee future was implemented.

Our company (and other companies we had this discussion with) sometimes suffered from lack of clear accountability when it came to carry out reviews on some changes. Especially changes with lots of reviewers added could get stuck for ages. It seemed that these all these reviewers counted on someone else to step up and carry out the actual review. Without clear assigned responsibility of whom should to step up to ensure that the change actually got closer to integration we would see unnecessary long lead times.

By assigning one of the reviewers as an "Assignee", that person had the ultimate responsibility to ensure that the change did not get stuck in review limbo. If the appointed Assignee could not review the change for whatever reason, the responsibility of the Assignee was to appoint someone else to actually carry out the review. This way, there would always be someone with full accountability. With that accountability there could be no excuses. If a new revision is expected from the change owner, the change owner could be given the role of "Assignee".

The concept of an assignee is well established in ticket systems and we argued that with out a clear "Assignee" in these ticket systems, most of them would be far less effective.

In our team the feature is used as intended. Far from all changes have an Assignee, but changes that needs to move through the process quickly will have a someone assigned to the Change. From my own observation this works really well. Changes that has someone assigned to them gets feedback _a lot_ quicker than changes without one. Clear accountability works.

I think adding someone as a reviewer can be seen as a request (it is called a "review request" after all). Setting an Assignee should be seen as an action point. 

Through extensions you could tweak the workflow to ensure that one maintainer does not gets assigned far too many changes (which would be indicative of a bottleneck). We also discussed writing a plugin that would assign one of the project owners to the change if it was unreviewed for a certain time, though it is not something we have actually tried.

What is described here is our reasoning for implementing the "Assignee"-feature and how we intended the workflow to work. Though I'm sure that many teams tweak the meaning of "Assignee" to fit their workflows.

IIRC there was discussion around this when the feature was implemented, and this is the reason that there is no enforcement of any specific workflow around "assignee" in Gerrit.  I.e. it leaves it open for teams to decide how they want to use it, if at all.

For instance I know that some teams iterate a change within a team for a while and when it is time to integrate the change, the code base owner would get assigned to it and would know that this particular change needs attention. This is good for prioritization, since some code base owners have _a lot_ of changes on their dashboard.  

If you have any ideas about the UX I would love to hear them. For us, I think the feature works pretty well.

/Gustaf

---

From: Patrick Hiesel <hie...@google.com>
Sent: Wednesday, November 7, 2018 5:07 PM
To: Sven Selberg; Gustaf Lundh
Cc: repo-d...@googlegroups.com
Subject: Usage of Assignee

 

Hi Sven and Gustaf,

I remember you implemented the assignee feature in Gerrit and wanted to cycle back to see how it is used at Axis (and potentially in other installations).

We recently got some feedback that users found this confusing because the distinction between a reviewer and an assignee was not clear to them.

We see usages in our installation where people use the field to pass around a change between the owner (needs to adapt code) and a single reviewer (needs to review). Do you see other usages? Is this feature widely used?

I am asking because with more insight into usage, we might be able to improve the UX a bit.

Thanks,

Patrick

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Luca Milanesio]

On 7 Nov 2018, at 23:24, David Pursehouse <david.pu...@gmail.com> wrote:

On Thu, Nov 8, 2018 at 6:09 AM Gustaf Lundh <gustaf...@axis.com> wrote:

Hi Patrick,

I'll do my best to reiterate the reasoning behind the "Assignee"-feature. We presented the same arguments during a presentation at the Hackathon where the assignee future was implemented.

Our company (and other companies we had this discussion with) sometimes suffered from lack of clear accountability when it came to carry out reviews on some changes. Especially changes with lots of reviewers added could get stuck for ages. It seemed that these all these reviewers counted on someone else to step up and carry out the actual review. Without clear assigned responsibility of whom should to step up to ensure that the change actually got closer to integration we would see unnecessary long lead times.

By assigning one of the reviewers as an "Assignee", that person had the ultimate responsibility to ensure that the change did not get stuck in review limbo. If the appointed Assignee could not review the change for whatever reason, the responsibility of the Assignee was to appoint someone else to actually carry out the review. This way, there would always be someone with full accountability. With that accountability there could be no excuses. If a new revision is expected from the change owner, the change owner could be given the role of "Assignee".

The concept of an assignee is well established in ticket systems and we argued that with out a clear "Assignee" in these ticket systems, most of them would be far less effective.

In our team the feature is used as intended. Far from all changes have an Assignee, but changes that needs to move through the process quickly will have a someone assigned to the Change. From my own observation this works really well. Changes that has someone assigned to them gets feedback _a lot_ quicker than changes without one. Clear accountability works.

I think adding someone as a reviewer can be seen as a request (it is called a "review request" after all). Setting an Assignee should be seen as an action point. 

Through extensions you could tweak the workflow to ensure that one maintainer does not gets assigned far too many changes (which would be indicative of a bottleneck). We also discussed writing a plugin that would assign one of the project owners to the change if it was unreviewed for a certain time, though it is not something we have actually tried.

What is described here is our reasoning for implementing the "Assignee"-feature and how we intended the workflow to work. Though I'm sure that many teams tweak the meaning of "Assignee" to fit their workflows.

IIRC there was discussion around this when the feature was implemented, and this is the reason that there is no enforcement of any specific workflow around "assignee" in Gerrit.  I.e. it leaves it open for teams to decide how they want to use it, if at all.

I recall that I posted a fix to hide the column when not used (GWT UX) but not sure that it is still working with PolyGerrit as well :-(

[Edwin Kempin]

On Thu, Nov 8, 2018 at 12:24 AM David Pursehouse <david.pu...@gmail.com> wrote:

On Thu, Nov 8, 2018 at 6:09 AM Gustaf Lundh <gustaf...@axis.com> wrote:

Hi Patrick,

I'll do my best to reiterate the reasoning behind the "Assignee"-feature. We presented the same arguments during a presentation at the Hackathon where the assignee future was implemented.

Our company (and other companies we had this discussion with) sometimes suffered from lack of clear accountability when it came to carry out reviews on some changes. Especially changes with lots of reviewers added could get stuck for ages. It seemed that these all these reviewers counted on someone else to step up and carry out the actual review. Without clear assigned responsibility of whom should to step up to ensure that the change actually got closer to integration we would see unnecessary long lead times.

By assigning one of the reviewers as an "Assignee", that person had the ultimate responsibility to ensure that the change did not get stuck in review limbo. If the appointed Assignee could not review the change for whatever reason, the responsibility of the Assignee was to appoint someone else to actually carry out the review. This way, there would always be someone with full accountability. With that accountability there could be no excuses. If a new revision is expected from the change owner, the change owner could be given the role of "Assignee".

The concept of an assignee is well established in ticket systems and we argued that with out a clear "Assignee" in these ticket systems, most of them would be far less effective.

In our team the feature is used as intended. Far from all changes have an Assignee, but changes that needs to move through the process quickly will have a someone assigned to the Change. From my own observation this works really well. Changes that has someone assigned to them gets feedback _a lot_ quicker than changes without one. Clear accountability works.

I think adding someone as a reviewer can be seen as a request (it is called a "review request" after all). Setting an Assignee should be seen as an action point. 

Through extensions you could tweak the workflow to ensure that one maintainer does not gets assigned far too many changes (which would be indicative of a bottleneck). We also discussed writing a plugin that would assign one of the project owners to the change if it was unreviewed for a certain time, though it is not something we have actually tried.

What is described here is our reasoning for implementing the "Assignee"-feature and how we intended the workflow to work. Though I'm sure that many teams tweak the meaning of "Assignee" to fit their workflows.

IIRC there was discussion around this when the feature was implemented, and this is the reason that there is no enforcement of any specific workflow around "assignee" in Gerrit.  I.e. it leaves it open for teams to decide how they want to use it, if at all.

Yes, this is also how I understood it.

However this makes the user experience bad. Users may not know which action is expected from them when they get a change assigned and the UI cannot show any in-product help because it doesn't know the workflow.

Another thing I find annoying is that I always have to manually unassign the change after doing the action (e.g. after doing a review, if the change was assigned to me for doing a review). Gerrit cannot help with automating this because it doesn't know the workflow.

In my opinion not defining a workflow is a problem. You can use it for many things, but none of these things work really great.

It also makes it hard to explain the assignee feature to users.

Just some examples how users may get confused:

* Some people see assignee as "mandatory reviewer", but this doesn't work because there

   is nothing that prevents submitting the change without approval from the assignee.

* "OK, the assignee is the person that must do the review, but why can an assignee be set on a merged changed?"

[Luca Milanesio]

On 8 Nov 2018, at 08:07, 'Edwin Kempin' via Repo and Gerrit Discussion <repo-d...@googlegroups.com> wrote:

On Thu, Nov 8, 2018 at 12:24 AM David Pursehouse <david.pu...@gmail.com> wrote:

On Thu, Nov 8, 2018 at 6:09 AM Gustaf Lundh <gustaf...@axis.com> wrote:

Hi Patrick,

I'll do my best to reiterate the reasoning behind the "Assignee"-feature. We presented the same arguments during a presentation at the Hackathon where the assignee future was implemented.

Our company (and other companies we had this discussion with) sometimes suffered from lack of clear accountability when it came to carry out reviews on some changes. Especially changes with lots of reviewers added could get stuck for ages. It seemed that these all these reviewers counted on someone else to step up and carry out the actual review. Without clear assigned responsibility of whom should to step up to ensure that the change actually got closer to integration we would see unnecessary long lead times.

By assigning one of the reviewers as an "Assignee", that person had the ultimate responsibility to ensure that the change did not get stuck in review limbo. If the appointed Assignee could not review the change for whatever reason, the responsibility of the Assignee was to appoint someone else to actually carry out the review. This way, there would always be someone with full accountability. With that accountability there could be no excuses. If a new revision is expected from the change owner, the change owner could be given the role of "Assignee".

The concept of an assignee is well established in ticket systems and we argued that with out a clear "Assignee" in these ticket systems, most of them would be far less effective.

In our team the feature is used as intended. Far from all changes have an Assignee, but changes that needs to move through the process quickly will have a someone assigned to the Change. From my own observation this works really well. Changes that has someone assigned to them gets feedback _a lot_ quicker than changes without one. Clear accountability works.

I think adding someone as a reviewer can be seen as a request (it is called a "review request" after all). Setting an Assignee should be seen as an action point. 

Through extensions you could tweak the workflow to ensure that one maintainer does not gets assigned far too many changes (which would be indicative of a bottleneck). We also discussed writing a plugin that would assign one of the project owners to the change if it was unreviewed for a certain time, though it is not something we have actually tried.

What is described here is our reasoning for implementing the "Assignee"-feature and how we intended the workflow to work. Though I'm sure that many teams tweak the meaning of "Assignee" to fit their workflows.

IIRC there was discussion around this when the feature was implemented, and this is the reason that there is no enforcement of any specific workflow around "assignee" in Gerrit.  I.e. it leaves it open for teams to decide how they want to use it, if at all.

Yes, this is also how I understood it.

However this makes the user experience bad. Users may not know which action is expected from them when they get a change assigned and the UI cannot show any in-product help because it doesn't know the workflow.

Another thing I find annoying is that I always have to manually unassign the change after doing the action (e.g. after doing a review, if the change was assigned to me for doing a review). Gerrit cannot help with automating this because it doesn't know the workflow.

In my opinion not defining a workflow is a problem. You can use it for many things, but none of these things work really great.

It also makes it hard to explain the assignee feature to users.

Just some examples how users may get confused:

* Some people see assignee as "mandatory reviewer", but this doesn't work because there

   is nothing that prevents submitting the change without approval from the assignee.

* "OK, the assignee is the person that must do the review, but why can an assignee be set on a merged changed?"

I see Gustaf point, however, I have never seen it used consistently.

With regards to the assignment and the similarity with Jira, actually the fact that there is only *one* person assigned to a ticket is a huge limitation because with Agile people are not "assigned" to a ticket but rather a pair or the Team is assigned to it.

Because it is a very loose concept in Gerrit (the assginee) then I propose to hide it by default, as we were doing with GWT.

P.S. None of our customers are using it, in GerritHub.io is rarely used also.

Luca.

[Gustaf Lundh]

On Thursday, November 8, 2018 at 9:14:17 AM UTC+1, lucamilanesio wrote:

I see Gustaf point, however, I have never seen it used consistently.

With regards to the assignment and the similarity with Jira, actually the fact that there is only *one* person assigned to a ticket is a huge limitation because with Agile people are not "assigned" to a ticket but rather a pair or the Team is assigned to it.

Because it is a very loose concept in Gerrit (the assginee) then I propose to hide it by default, as we were doing with GWT.

P.S. None of our customers are using it, in GerritHub.io is rarely used also.

Luca.

I would have to disagree here. Many people makes use of it and I never gotten complains about it "being in the way" for teams that not use it. It is one of the features in Gerrit that does not seem to cause that kind of confusion. The teams that does introduce it in their workflow (in any way) never seem to go back to not using it.

For what it is worth, it is very well used on https://android-review.googlesource.com/q/is:assigned . And AFAIK they had this as a feature request before it was implemented. 

/Gustaf

[Luca Milanesio]

https://review.gerrithub.io/q/is:assigned as well shows utilisation, I have overstated my "rarely" and I would change it "percentage" :-)

Luca.

And AFAIK they had this as a feature request before it was implemented. 

/Gustaf

[Luca Milanesio]

On 8 Nov 2018, at 08:30, Luca Milanesio <Luca.Mi...@gmail.com> wrote:

On 8 Nov 2018, at 08:26, Gustaf Lundh <gustaf...@axis.com> wrote:

On Thursday, November 8, 2018 at 9:14:17 AM UTC+1, lucamilanesio wrote:

I see Gustaf point, however, I have never seen it used consistently.

With regards to the assignment and the similarity with Jira, actually the fact that there is only *one* person assigned to a ticket is a huge limitation because with Agile people are not "assigned" to a ticket but rather a pair or the Team is assigned to it.

Because it is a very loose concept in Gerrit (the assginee) then I propose to hide it by default, as we were doing with GWT.

P.S. None of our customers are using it, in GerritHub.io is rarely used also.

Luca.

I would have to disagree here. Many people makes use of it and I never gotten complains about it "being in the way" for teams that not use it. It is one of the features in Gerrit that does not seem to cause that kind of confusion. The teams that does introduce it in their workflow (in any way) never seem to go back to not using it.

For what it is worth, it is very well used on https://android-review.googlesource.com/q/is:assigned . 

https://review.gerrithub.io/q/is:assigned as well shows utilisation, I have overstated my "rarely" and I would change it "percentage" :-)

Why don't we do a bit of data-mining on GerritHub and Android and try to answer the question "How is the people using it?"

In my experience, very often people uses a feature in a different way that it was originally designed.

Luca.

[Edwin Kempin]

On Thu, Nov 8, 2018 at 9:38 AM Luca Milanesio <luca.mi...@gmail.com> wrote:

On 8 Nov 2018, at 08:30, Luca Milanesio <Luca.Mi...@gmail.com> wrote:

On 8 Nov 2018, at 08:26, Gustaf Lundh <gustaf...@axis.com> wrote:

On Thursday, November 8, 2018 at 9:14:17 AM UTC+1, lucamilanesio wrote:

I see Gustaf point, however, I have never seen it used consistently.

With regards to the assignment and the similarity with Jira, actually the fact that there is only *one* person assigned to a ticket is a huge limitation because with Agile people are not "assigned" to a ticket but rather a pair or the Team is assigned to it.

Because it is a very loose concept in Gerrit (the assginee) then I propose to hide it by default, as we were doing with GWT.

P.S. None of our customers are using it, in GerritHub.io is rarely used also.

Luca.

I would have to disagree here. Many people makes use of it and I never gotten complains about it "being in the way" for teams that not use it. It is one of the features in Gerrit that does not seem to cause that kind of confusion. The teams that does introduce it in their workflow (in any way) never seem to go back to not using it.

For what it is worth, it is very well used on https://android-review.googlesource.com/q/is:assigned . 

https://review.gerrithub.io/q/is:assigned as well shows utilisation, I have overstated my "rarely" and I would change it "percentage" :-)

Why don't we do a bit of data-mining on GerritHub and Android and try to answer the question "How is the people using it?"

In my experience, very often people uses a feature in a different way that it was originally designed.

Just to avoid misunderstandings. I do think that this feature is useful and that many people use it.

But, the UX is not great and it's hard to improve the UX if Gerrit doesn't know the workflow for which it is used.

I wish we would understand these workflows and build dedicated support for them.

So yes, finding out how people use it would be great.

[Luca Milanesio]

On 8 Nov 2018, at 08:47, Edwin Kempin <eke...@google.com> wrote:

On Thu, Nov 8, 2018 at 9:38 AM Luca Milanesio <luca.mi...@gmail.com> wrote:

On 8 Nov 2018, at 08:30, Luca Milanesio <Luca.Mi...@gmail.com> wrote:

On 8 Nov 2018, at 08:26, Gustaf Lundh <gustaf...@axis.com> wrote:

On Thursday, November 8, 2018 at 9:14:17 AM UTC+1, lucamilanesio wrote:

I see Gustaf point, however, I have never seen it used consistently.

With regards to the assignment and the similarity with Jira, actually the fact that there is only *one* person assigned to a ticket is a huge limitation because with Agile people are not "assigned" to a ticket but rather a pair or the Team is assigned to it.

Because it is a very loose concept in Gerrit (the assginee) then I propose to hide it by default, as we were doing with GWT.

P.S. None of our customers are using it, in GerritHub.io is rarely used also.

Luca.

I would have to disagree here. Many people makes use of it and I never gotten complains about it "being in the way" for teams that not use it. It is one of the features in Gerrit that does not seem to cause that kind of confusion. The teams that does introduce it in their workflow (in any way) never seem to go back to not using it.

For what it is worth, it is very well used on https://android-review.googlesource.com/q/is:assigned . 

https://review.gerrithub.io/q/is:assigned as well shows utilisation, I have overstated my "rarely" and I would change it "percentage" :-)

Why don't we do a bit of data-mining on GerritHub and Android and try to answer the question "How is the people using it?"

In my experience, very often people uses a feature in a different way that it was originally designed.

Just to avoid misunderstandings. I do think that this feature is useful and that many people use it.

Yes, the fact that people is using it (we need to find out how many and how) is a clear evidence of that.

Apologies for having created the misunderstanding, hope it is clarified now :-)

But, the UX is not great and it's hard to improve the UX if Gerrit doesn't know the workflow for which it is used.

I wish we would understand these workflows and build dedicated support for them.

So yes, finding out how people use it would be great.

Tony and Ponch are working on the Gerrit Analytics effort and its main goal is to "crunch Gerrit" to understand users', projects and system behaviour from data.

This could be an interesting exercise for them for the Hackathon, isn't it?

Luca.

[Patrick Hiesel]

Thanks for the discussion. To be clear: I didn't start this discussion with the intention of having 'assignee' removed, but to get insight into usage and to see if there are smaller bits we could tweak to make it more UX friendly.

Looking at public Android, I see two different ways of how the feature is used:

1) Users (probably) don't understand the difference between assignee and reviewer and assign both to a single person: https://android-review.googlesource.com/c/platform/packages/apps/Dialer/+/694784

(actually, this happens a lot: https://android-review.googlesource.com/c/platform/frameworks/base/+/818193)

2) Multiple reviewers with 'assignee' being the primary one: https://android-review.googlesource.com/c/platform/frameworks/support/+/784597

3) Passing around a change between owner/reviewer to take action (I found no example, but have seen some on internal hosts)

So the question for me is how can we mitigate (1) while still enabling (2) + (3)?

Maybe we could tweak the UI so that instead of being able to assign to any user, you can only assign to a reviewer or the change owner? This would put more emphasis on the intended use and if we do it the right way there would be a chance we mitigate (1).

What do you think?

[Gustaf Lundh]

On Thursday, November 8, 2018 at 1:58:35 PM UTC+1, Patrick Hiesel wrote:

Thanks for the discussion. To be clear: I didn't start this discussion with the intention of having 'assignee' removed, but to get insight into usage and to see if there are smaller bits we could tweak to make it more UX friendly.

Looking at public Android, I see two different ways of how the feature is used:

1) Users (probably) don't understand the difference between assignee and reviewer and assign both to a single person: https://android-review.googlesource.com/c/platform/packages/apps/Dialer/+/694784

Just because there is one reviewer and the very same is the Assignee, I don't think we necessarily can draw those very conclusions. For instance, in this case it was the reviewer and not the change owner that made the assignment.

I can only guess, but (s)he may wanted to show other maintainers that (s)he intended to handle this change.

In other cases a maintainer may have 100 of changes in his dashboard. Looking at the dashboard the maintainer wont know that (s)he is the only reviewer on a specific change. By assigning it, it will be highlighted and the maintainer will directly know that input is needed from him/her specifically.

 /Gustaf

[David Ostrovsky]

Am Donnerstag, 8. November 2018 13:58:35 UTC+1 schrieb Patrick Hiesel:

Thanks for the discussion. To be clear: I didn't start this discussion with the intention of having 'assignee' removed, but to get insight into usage and to see if there are smaller bits we could tweak to make it more UX friendly.

Looking at public Android, I see two different ways of how the feature is used:

1) Users (probably) don't understand the difference between assignee and reviewer and assign both to a single person: https://android-review.googlesource.com/c/platform/packages/apps/Dialer/+/694784

(actually, this happens a lot: https://android-review.googlesource.com/c/platform/frameworks/base/+/818193)

2) Multiple reviewers with 'assignee' being the primary one: https://android-review.googlesource.com/c/platform/frameworks/support/+/784597

3) Passing around a change between owner/reviewer to take action (I found no example, but have seen some on internal hosts)

3) would be similar to "Work In Progress" workflow (though, "assignee" feature pre-dated WIP support in Gerrit core).

By marking change as WIP, change owner clearly indicates that she is responsible for the next step: making the

change reviewable again. WIP workflow has also other implications, like stream events, dashboards and notification

firehouse. Marking the change as "Ready For Review" is a clear action call for the reviewer to take over and

review the change.

[Gustaf Lundh]

Not really. A reviewer can assign the change back to the Change Owner to request clarifications, comments or new revisions. WIP is initiated by the Change Owner at the Change Owner's own discretion. Big difference.

/Gustaf