I confirm that I see "Unresolve discussion" buttons in the "Discussion" page, after "Toggle Discussion" is clicked.

Perhaps we have this working convention: the dev that starts the discussion is expected to resolve it. I doubt GL can enforce that convention, but we can just agree to it all. So, in the case at hand, I wrote the patch, and Simon started several discussions. As I address them, instead of resolving the discussions (as I did), I would just say "Done" (or similar). Then, Simon's re-review would spot my comments and then click resolve, when the matter has met his satisfaction.

Ben: I imagine this will not be the only such convention we arrive at in this vein. Is it possible (and reasonably easy) to set up some service whereby new contributors get a "welcome" email upon their first submission of an MR? (But only upon the *first* submission!) This would include hearty thanks for contributing, etc., but also a few GL pointers and our working conventions. To be honest, even forgetting about working conventions, an email of thanks at that stage would probably set the stage for a nice working environment for contributors. (Right now, they probably submit, get some silence, then see a slew of comments telling them what they've done wrong, and then get a "Thanks so much!" after all those negative comments. This may be somewhat standard in open-source -- and isn't so bad that it *needs* change -- but that doesn't mean we can't do better.)

Richard

On Jan 14, 2019, at 7:30 AM, Mikolaj Konarski <mikolaj@well-typed.com> wrote:

On Mon, Jan 14, 2019 at 10:28 AM Simon Peyton Jones via ghc-devs <ghc-devs@haskell.org> wrote:
>
> I suppose we could issue guidance NEVER to resolve a discussion, but that seems like the wrong conclusion.

It seems gitlab's "resolve discussion" action is supposed to mean
"I think nobody needs to look at these comments (in detail) any more".

So if somebody addressed your comment, he should probably
ping you with "this comment addressed", then you look at the comment,
at the old diff, at the new diff (no idea how easy it is to switch between
the old and new diffs) and then *you* resolve the discussion, if satisfied.
And if somebody resolves discussion prematurely, you unresolve it
with the button or checkbox, meaning "actually, I'd like to have
one more close look before the discussion is hidden forever".
You can even add an unresolve comment explaining why you think
the additional look is needed after all.

All this is quite troublesome if there is a lot of comments
and they need to be pinged about, resolved and unresolved
in bulk (unless I'm missing some bulk button).

_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs