reviewing on GitLab

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

reviewing on GitLab

Richard Eisenberg-5
Hi all,

I've just reviewed !364, and it was a painful experience. Perhaps documenting why will help spur more UI innovations.

- My review was in response to several of the author's in-line comments, which themselves were in response to previous in-line comments. This has to be a common scenario.

- The *only* place I could get a simple listing of all the new comments was in my notification email. Neither the Discussion tab nor the Changes tab on GitLab allow me to collect recent comments, as they new comments are placed directly below the old comments, each of which started at different points in time.

- The Discussions tab has all the comments somewhere. But for each comment, I had to search (with Ctrl+F) on the page to find the corresponding comment trail, so I could get context. The order on the Discussions tab was unrelated to the order in my email.

- Actually, not all comments were on the Discussions page, because the commit author had *resolved* a discussion. In this case, though, I still wanted to comment. So I had to search (with Ctrl+F) for "resolved" so I could find the comment trail and unresolve it.

- The Changes page has much more code context than the Discussions page. So I had that open, too, so I could scroll through the code. Not all the comments appeared on the Changes page, because the most interesting, most important files are always hidden by default. Even after expanding the relevant files, the comment trails did not always appear. Perhaps 30 seconds wasn't enough waiting.

- All this means that this was my workflow:
  1. Scroll through my notification email to see the author's next comment.
  2. Ctrl+F with the text of that comment to find it on the Discussion tab. (Ctrl+F for "resolved" if the first search fails.)
  3. If necessary, then use the line numbers and source file names from the Discussions tab to find the the relevant code in the Changes tab... which were often offset by a few lines, as things churn.

I needed three windows open to complete a fairly simple review!

I believe this is easy to fix: make the Discussions tab *chronological*. And have a link from the comment on the Discussions page to the Changes page that warps you to just the right spot in the code, with the full commentary context. (Right now, the link from the Discussions page just brings you to the file in the Changes page, not the line.)

I know this isn't the first time we've suggested this or complained, but I'm not aware of progress (or even "it's on our queue") from GitLab. Has that happened? Is there a way to prioritize this? This review process is really a drag!

Many thanks,
Richard
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

RE: reviewing on GitLab

GHC - devs mailing list
I agree.  It's frustrating.

I spent quite a bit of effort distilling ideas to help make GitLab better here: https://docs.google.com/document/d/1sdGlDJSTiBZSH6kBU5pyn1HASE9XFqQhzILcYcH1QJQ/edit?usp=sharing

We shared those ideas with them, and I believe they promised to think about them.  I think would be reasonable to ask them politely whether they see any merit in them, whether there is any chance they might get implemented, and whether they would be willing to engage in a dialogue with us about them.

Issue #1 is by far the most important.

Richard: you might want to elaborate the document with any new problems you have now uncovered.

Simon

| -----Original Message-----
| From: ghc-devs <[hidden email]> On Behalf Of Richard
| Eisenberg
| Sent: 06 June 2019 20:34
| To: Simon Peyton Jones via ghc-devs <[hidden email]>
| Subject: reviewing on GitLab
|
| Hi all,
|
| I've just reviewed !364, and it was a painful experience. Perhaps
| documenting why will help spur more UI innovations.
|
| - My review was in response to several of the author's in-line comments,
| which themselves were in response to previous in-line comments. This has
| to be a common scenario.
|
| - The *only* place I could get a simple listing of all the new comments
| was in my notification email. Neither the Discussion tab nor the Changes
| tab on GitLab allow me to collect recent comments, as they new comments
| are placed directly below the old comments, each of which started at
| different points in time.
|
| - The Discussions tab has all the comments somewhere. But for each
| comment, I had to search (with Ctrl+F) on the page to find the
| corresponding comment trail, so I could get context. The order on the
| Discussions tab was unrelated to the order in my email.
|
| - Actually, not all comments were on the Discussions page, because the
| commit author had *resolved* a discussion. In this case, though, I still
| wanted to comment. So I had to search (with Ctrl+F) for "resolved" so I
| could find the comment trail and unresolve it.
|
| - The Changes page has much more code context than the Discussions page.
| So I had that open, too, so I could scroll through the code. Not all the
| comments appeared on the Changes page, because the most interesting, most
| important files are always hidden by default. Even after expanding the
| relevant files, the comment trails did not always appear. Perhaps 30
| seconds wasn't enough waiting.
|
| - All this means that this was my workflow:
|   1. Scroll through my notification email to see the author's next
| comment.
|   2. Ctrl+F with the text of that comment to find it on the Discussion
| tab. (Ctrl+F for "resolved" if the first search fails.)
|   3. If necessary, then use the line numbers and source file names from
| the Discussions tab to find the the relevant code in the Changes tab...
| which were often offset by a few lines, as things churn.
|
| I needed three windows open to complete a fairly simple review!
|
| I believe this is easy to fix: make the Discussions tab *chronological*.
| And have a link from the comment on the Discussions page to the Changes
| page that warps you to just the right spot in the code, with the full
| commentary context. (Right now, the link from the Discussions page just
| brings you to the file in the Changes page, not the line.)
|
| I know this isn't the first time we've suggested this or complained, but
| I'm not aware of progress (or even "it's on our queue") from GitLab. Has
| that happened? Is there a way to prioritize this? This review process is
| really a drag!
|
| Many thanks,
| Richard
| _______________________________________________
| ghc-devs mailing list
| [hidden email]
| http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: reviewing on GitLab

Richard Eisenberg-5
Very helpfully, that document now has GitLab issue numbers. I just pinged the one about the discussions tab.

One issue in that document that doesn't have a GitLab Issue number is "Issue 5: Prioritising numbers". Ben (or others who have interfaced with GL central): has this been reported upstream? I'm reluctant to do so without the context of our collaboration.

Thanks,
Richard

> On Jun 6, 2019, at 6:01 PM, Simon Peyton Jones <[hidden email]> wrote:
>
> I agree.  It's frustrating.
>
> I spent quite a bit of effort distilling ideas to help make GitLab better here: https://docs.google.com/document/d/1sdGlDJSTiBZSH6kBU5pyn1HASE9XFqQhzILcYcH1QJQ/edit?usp=sharing
>
> We shared those ideas with them, and I believe they promised to think about them.  I think would be reasonable to ask them politely whether they see any merit in them, whether there is any chance they might get implemented, and whether they would be willing to engage in a dialogue with us about them.
>
> Issue #1 is by far the most important.
>
> Richard: you might want to elaborate the document with any new problems you have now uncovered.
>
> Simon
>
> | -----Original Message-----
> | From: ghc-devs <[hidden email]> On Behalf Of Richard
> | Eisenberg
> | Sent: 06 June 2019 20:34
> | To: Simon Peyton Jones via ghc-devs <[hidden email]>
> | Subject: reviewing on GitLab
> |
> | Hi all,
> |
> | I've just reviewed !364, and it was a painful experience. Perhaps
> | documenting why will help spur more UI innovations.
> |
> | - My review was in response to several of the author's in-line comments,
> | which themselves were in response to previous in-line comments. This has
> | to be a common scenario.
> |
> | - The *only* place I could get a simple listing of all the new comments
> | was in my notification email. Neither the Discussion tab nor the Changes
> | tab on GitLab allow me to collect recent comments, as they new comments
> | are placed directly below the old comments, each of which started at
> | different points in time.
> |
> | - The Discussions tab has all the comments somewhere. But for each
> | comment, I had to search (with Ctrl+F) on the page to find the
> | corresponding comment trail, so I could get context. The order on the
> | Discussions tab was unrelated to the order in my email.
> |
> | - Actually, not all comments were on the Discussions page, because the
> | commit author had *resolved* a discussion. In this case, though, I still
> | wanted to comment. So I had to search (with Ctrl+F) for "resolved" so I
> | could find the comment trail and unresolve it.
> |
> | - The Changes page has much more code context than the Discussions page.
> | So I had that open, too, so I could scroll through the code. Not all the
> | comments appeared on the Changes page, because the most interesting, most
> | important files are always hidden by default. Even after expanding the
> | relevant files, the comment trails did not always appear. Perhaps 30
> | seconds wasn't enough waiting.
> |
> | - All this means that this was my workflow:
> |   1. Scroll through my notification email to see the author's next
> | comment.
> |   2. Ctrl+F with the text of that comment to find it on the Discussion
> | tab. (Ctrl+F for "resolved" if the first search fails.)
> |   3. If necessary, then use the line numbers and source file names from
> | the Discussions tab to find the the relevant code in the Changes tab...
> | which were often offset by a few lines, as things churn.
> |
> | I needed three windows open to complete a fairly simple review!
> |
> | I believe this is easy to fix: make the Discussions tab *chronological*.
> | And have a link from the comment on the Discussions page to the Changes
> | page that warps you to just the right spot in the code, with the full
> | commentary context. (Right now, the link from the Discussions page just
> | brings you to the file in the Changes page, not the line.)
> |
> | I know this isn't the first time we've suggested this or complained, but
> | I'm not aware of progress (or even "it's on our queue") from GitLab. Has
> | that happened? Is there a way to prioritize this? This review process is
> | really a drag!
> |
> | Many thanks,
> | Richard
> | _______________________________________________
> | ghc-devs mailing list
> | [hidden email]
> | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: reviewing on GitLab

Ben Gamari-3
Richard Eisenberg <[hidden email]> writes:

> Very helpfully, that document now has GitLab issue numbers. I just
> pinged the one about the discussions tab.
>
> One issue in that document that doesn't have a GitLab Issue number is
> "Issue 5: Prioritising numbers". Ben (or others who have interfaced
> with GL central): has this been reported upstream? I'm reluctant to do
> so without the context of our collaboration.
>
Hi Richard,

Alp dug up a few previous issues requesting a number-centric UI (#21712
and #1734; references added to document). For better or worse, both have
been closed, one merge request changing the behavior ended in a revert,
and at least some GitLab contributors believe that titles make for a
better identifier. Regardless, I think there is a strong argument to be
made that this should at very least be configurable; we can try to make
this argument.

Cheers,

- Ben


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: reviewing on GitLab

Ben Gamari-3
In reply to this post by Richard Eisenberg-5
Richard Eisenberg <[hidden email]> writes:

> Hi all,
>
> I've just reviewed !364, and it was a painful experience. Perhaps
> documenting why will help spur more UI innovations.
>
Indeed. Thanks for making sure these issues don't fall by the wayside.

> I believe this is easy to fix: make the Discussions tab
> *chronological*. And have a link from the comment on the Discussions
> page to the Changes page that warps you to just the right spot in the
> code, with the full commentary context. (Right now, the link from the
> Discussions page just brings you to the file in the Changes page, not
> the line.)
>
> I know this isn't the first time we've suggested this or complained,
> but I'm not aware of progress (or even "it's on our queue") from
> GitLab. Has that happened? Is there a way to prioritize this? This
> review process is really a drag!
>
Simon and I had a discussion with James Ramsey, a project manager with
GitLab, around Simon's document a few months ago. They identified their
first priority as work on merge queue infrastructure (another request of
ours, although it's not on Simon's list); this work is tracked as
gitlab-ee#9186 and a version of it will be shipped in GitLab 12.0, next
month's release.

James made it clear that another of his priorities for this year was to
look at the current discussion interface and try to mitigate the sorts
of problems that we are encountering. Simon proposed that the situation
could be improved by presenting comments chronologically. James found
this to be an interesting suggestion and said he would add it to his
bucket of ideas.

With respect to timing: There were understandably no concrete timelines
given. James said that work on the discussion model would likely only
happen in the second half of the year (which we are now just entering).
Since then work on the merge train infrastructure has progressed a bit
more slower than expected, so I suspect things may happen a bit later
than expected. Moreover, neither gitlab-org&855 nor gitlab-ce#56481 have
milestones yet so I expect the timescale is at least on the order of
several months, unfortunately.

Cheers,

- Ben

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: reviewing on GitLab

Richard Eisenberg-5
Thanks, Ben, for this summary. I am happy to wait for a resolution -- as long as there is some hope that waiting will not be in vain. This email indeed gives me this hope.

And, for the record, I agree that the merge-train support should be significantly higher priority. The whole merge scenario has caused much more trouble than a poor UI for reviewing.

Thanks!
Richard

On Jun 6, 2019, at 9:28 PM, Ben Gamari <[hidden email]> wrote:

Simon and I had a discussion with James Ramsey, a project manager with
GitLab, around Simon's document a few months ago. They identified their
first priority as work on merge queue infrastructure (another request of
ours, although it's not on Simon's list); this work is tracked as
gitlab-ee#9186 and a version of it will be shipped in GitLab 12.0, next
month's release.

James made it clear that another of his priorities for this year was to
look at the current discussion interface and try to mitigate the sorts
of problems that we are encountering. Simon proposed that the situation
could be improved by presenting comments chronologically. James found
this to be an interesting suggestion and said he would add it to his
bucket of ideas.

With respect to timing: There were understandably no concrete timelines
given. James said that work on the discussion model would likely only
happen in the second half of the year (which we are now just entering).
Since then work on the merge train infrastructure has progressed a bit
more slower than expected, so I suspect things may happen a bit later
than expected. Moreover, neither gitlab-org&855 nor gitlab-ce#56481 have
milestones yet so I expect the timescale is at least on the order of
several months, unfortunately.


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs