
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

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/1sdGlDJSTiBZSH6kBU5pyn1HASE9XFqQhzILcYcH1...
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

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
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/1sdGlDJSTiBZSH6kBU5pyn1HASE9XFqQhzILcYcH1...
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
On Behalf Of Richard | Eisenberg | Sent: 06 June 2019 20:34 | To: Simon Peyton Jones via ghc-devs | 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 | ghc-devs@haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Richard Eisenberg
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

Richard Eisenberg
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

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
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.
participants (3)
-
Ben Gamari
-
Richard Eisenberg
-
Simon Peyton Jones