<div dir="ltr"><div></div><div>One common technique is to put all the MR instructions gobbedlygook into a <!-- html comment -->, so they don't end up in the actual description. I kind of agree the gobbeldy gook should be on the wiki, though, with a simple <!-- See the merge request guide at <a href="https://url/to/guide">https://url/to/guide</a> --> in the actual template itself. But even that kind of falls down because the link wouldn't actually be clickable. Maybe a big comment is fine.<br></div><div><br></div><div>At any rate, +1 to making the template an actual template.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 27 Jun 2023 at 12:35, Simon Peyton Jones <<a href="mailto:simon.peytonjones@gmail.com">simon.peytonjones@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>The majority of contributors don't have the rights to modify labels
 on merge requests. It might be good to add a few words of advice for 
that group: What should *they* do if their MR needs attention?</div></blockquote><div><br></div><div>Oh!  That is bad.  It's no good us saying "add label X" if they can't add a label.  Can we give everyone rights to modify labels?</div><div><br></div><div>Also: I have noticed that many MRs (hilariously including !10709) start with "Thank you for your contribution to GHC".  That always irritates me: it suggests that the author has not really bothered to write a proper MR description.   The template isn't really a template: it's more <i>guidance </i>about how to submit a MR, which we also supply at <a href="https://gitlab.haskell.org/ghc/ghc/-/wikis/Contributing-a-Patch" target="_blank">https://gitlab.haskell.org/ghc/ghc/-/wikis/Contributing-a-Patch</a>.    (And if the template is widely used, as it seems to be though I don't know how people find it initially, it should point to that wiki page.)<br></div><div><br></div><div>I'm not quite sure how to resolve this.  Maybe make the template be truly a template, and point to the wiki page for all content?</div><div><br></div><div>Simon<br></div>

</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 27 Jun 2023 at 06:53, Bryan Richter <bryan@haskell.foundation> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>The majority of contributors don't have the rights to modify labels on merge requests. It might be good to add a few words of advice for that group: What should *they* do if their MR needs attention?</div><div><br></div><div>Thanks for this effort! The vast, vast majority of GHC contributors are the ones who haven't even heard of it yet, or aren't even born yet. High quality information on how things work and how to get started will be the key to growing the ranks of GHC experts over time.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 23 Jun 2023 at 18:40, Matthew Pickering <<a href="mailto:matthewtpickering@gmail.com" target="_blank">matthewtpickering@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I have modified the MR template -<br>
<a href="https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10709" rel="noreferrer" target="_blank">https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10709</a><br>
<br>
and updated the wiki page that simon points out.<br>
<br>
Matt<br>
<br>
On Fri, Jun 23, 2023 at 11:25 AM Simon Peyton Jones<br>
<<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a>> wrote:<br>
><br>
> Terrific.<br>
><br>
> We just need to add some guidance for contributors about when and how to use the new tag.<br>
><br>
> Where should that guidance live?  We have the Contributing to GHC wiki page.  It in turn (not very prominently) points to Contributing a patch.  Are these our primary pages?  If so, perhaps the latter is the one to edit?<br>
><br>
> Simon<br>
><br>
><br>
><br>
> On Fri, 23 Jun 2023 at 11:14, Matthew Pickering <<a href="mailto:matthewtpickering@gmail.com" target="_blank">matthewtpickering@gmail.com</a>> wrote:<br>
>><br>
>> We discussed this in the meeting on Tuesday.<br>
>><br>
>> The conclusion was that<br>
>><br>
>> * We now have a new label "Blocked on Review", which people can add to<br>
>> merge requests if they are blocked waiting for a review.<br>
>> * The "Reviewer Group" is taken to be the same as the "GHC Team" (see<br>
>> <a href="https://gitlab.haskell.org/ghc/ghc-hq/-/tree/main" rel="noreferrer" target="_blank">https://gitlab.haskell.org/ghc/ghc-hq/-/tree/main</a>), hence people<br>
>> trusted to be part of the GHC team are expected to perform review as<br>
>> well.<br>
>> * We will take up some of the time on the Tuesday meeting by talking<br>
>> about merge requests which are blocked and assigning them to people<br>
>> for review.<br>
>><br>
>> Cheers,<br>
>><br>
>> Matt<br>
>><br>
>> On Mon, Jun 19, 2023 at 10:03 PM Matthew Pickering<br>
>> <<a href="mailto:matthewtpickering@gmail.com" target="_blank">matthewtpickering@gmail.com</a>> wrote:<br>
>> ><br>
>> > Hi all,<br>
>> ><br>
>> > Recently there has been some discussion about better systems and<br>
>> > processes for keeping the flow of merge requests going smoothly<br>
>> > through the review process. It has become clear that we need to be a<br>
>> > bit more deliberate in handling merge requests in order to make sure<br>
>> > we can correctly triage, review and merge the many fantastic<br>
>> > contributions we get to GHC on a daily basis.<br>
>> ><br>
>> > Therefore we are proposing to introduce a "GHC Reviewer Group" whose<br>
>> > members will share collective responsibility for ensuring that MRs<br>
>> > make their way smoothly from creation to merge.<br>
>> ><br>
>> > The description of the role and responsibility for this group can be<br>
>> > read and commented on here:<br>
>> ><br>
>> > <a href="https://docs.google.com/document/d/1FK9mryjC82DM6e5yxP7BOgu94As2bXccb55L8OrjPf4/edit?usp=sharing" rel="noreferrer" target="_blank">https://docs.google.com/document/d/1FK9mryjC82DM6e5yxP7BOgu94As2bXccb55L8OrjPf4/edit?usp=sharing</a><br>
>> ><br>
>> > The motivation for this proposal is two-fold.<br>
>> ><br>
>> > * Ensuring that MRs are reviewed and triaged in a timely manner.<br>
>> > * Documenting where the responsibility for MR reviewing<br>
>> ><br>
>> > We welcome any discussion about this document and other ideas about<br>
>> > how to improve the systems in this regard.<br>
>> ><br>
>> > Cheers,<br>
>> ><br>
>> > Matt<br>
>> _______________________________________________<br>
>> ghc-devs mailing list<br>
>> <a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>
</blockquote></div>
</blockquote></div>