<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">That is a great point; it's easy for me to forget how I felt when I was<br></span><span style="font-size:12.8px">a beginner. I've added a brief paragraph to the Newcomers page,</span><br style="font-size:12.8px"><span style="font-size:12.8px">    If you have any questions along the way don't hesitate to reach out<br></span><span style="font-size:12.8px">    to the community. There are people on the mailing lists and IRC who<br></span><span style="font-size:12.8px">    will gladly help you (although you may need to be patient). Don't<br></span><span style="font-size:12.8px">    forget that all GHC developers are still learning; your question is<br></span><span style="font-size:12.8px">    never too silly to ask.</span><br style="font-size:12.8px"><span style="font-size:12.8px">Can you see any way this could be improved?</span></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">That is a fair point; I've added some language to the Newcomers page<br></span><span style="font-size:12.8px">encouraging these sorts of inqueries,</span><br style="font-size:12.8px"><span style="font-size:12.8px">    == Finding a ticket ==</span><br style="font-size:12.8px"><span style="font-size:12.8px">    Now that you can build GHC, let's get hacking. But first, you'll<br></span><span style="font-size:12.8px">    need to identify a goal. GHC's Trac tickets are a great place to<br></span><span style="font-size:12.8px">    find starting points. You are encouraged to ask for a starting point<br></span><span style="font-size:12.8px">    on IRC or the ghc-devs mailing list. There someone familiar with the<br></span><span style="font-size:12.8px">    process can help you find a ticket that matches your expertise and<br></span><span style="font-size:12.8px">    help you when troubles arise.</span><br style="font-size:12.8px"><span style="font-size:12.8px">    If you want to get a taste for possible starting tasks, below is a<br></span><span style="font-size:12.8px">    list of tickets that appear to be "low-hanging fruit" -- things that<br></span><span style="font-size:12.8px">    might be reasonable for a newcomer to GHC hacking. Of course, we<br></span><span style="font-size:12.8px">    can't ever be sure of how hard a task is before doing it, so<br></span><span style="font-size:12.8px">    apologies if one of these is too hard.</span><br style="font-size:12.8px"><span style="font-size:12.8px">Is this better?</span></blockquote><div><br></div><div>I think both of these are great. Thanks!</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 26, 2016 at 2:51 PM, Ben Gamari <span dir="ltr"><<a href="mailto:ben@smart-cactus.org" target="_blank">ben@smart-cactus.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Simon Marlow <<a href="mailto:marlowsd@gmail.com">marlowsd@gmail.com</a>> writes:<br>
<br>
> But this is opening the floodgates a crack... how do we know what a "small"<br>
> patch is?  What happens when someone submits a patch that's too large?<br>
><br>
</span>I tried to address these questions in the "Create a<br>
ghc-simple-patch-propose list?" thread where I said,<br>
<br>
Ben Gamari <<a href="mailto:ben@smart-cactus.org">ben@smart-cactus.org</a>> writes:<br>
<br>
> I completely agree that for small (e.g. documentation) patches our<br>
> current system is quite heavy. For this reason I suggested at ICFP that<br>
> we simply begin accepting small patches via GitHub pull requests.<br>
> Frankly, this is less work for me than merging patches from a mailing<br>
> list and I believe many users feel that GitHub is more accessible than a<br>
> mailing list.<br>
><br>
> The problem of course is what subset of patches do we want to allow to<br>
> be taken via GitHub. My suggested answer to that is any patch which, if<br>
> I were to write it myself, I would feel comfortable pushing directly to<br>
> the tree.<br>
><br>
> Then there is the question of what do we do with pull requests opened<br>
> which do not satisfy this criterion. In this case I would likely open a<br>
> Phabricator Differential with the pull request and close the pull<br>
> request with a link to the Diff. In the ideal case this will inspire the<br>
> contributor to join the review process on Phabricator; in the worst case<br>
> review turns up issues in the patch and the user gives up. Either way, at<br>
> least the contributor feels his patch has been seen and given the<br>
> attention it deserves.<br>
<br>
Does this help?<br>
<span class=""><br>
<br>
Simon Marlow <<a href="mailto:marlowsd@gmail.com">marlowsd@gmail.com</a>> writes:<br>
<br>
> The patches will get larger, we'll have to do code reviews on two<br>
> different tools, and it will be really hard to go back. I just have a<br>
> bad feeling about this.<br>
><br>
</span>I share your worry that the GitHub patch sizes will "creep". That being<br>
said, I think that as long as we can easily move to Phabricator for<br>
reviewing larger patches it will be manageable.<br>
<br>
Moreover, I suspect that once someone has submitted a patch via GitHub,<br>
the effort that they have sunk into it will mean that they will be more<br>
likely to follow the patch to Phabricator to participate in review (and<br>
hopefully revision) if we move it.<br>
<span class=""><br>
>> It does certainly put yet another task on our plates, but I would argue<br>
>> that it's actually easier than accepting patches via Trac, which we<br>
>> already do.<br>
><br>
> We should stop accepting patches via Trac too :)<br>
><br>
</span>Heh, it would certainly make my life easier. That being said, there<br>
(thankfully) aren't too many that come in via this channel at this<br>
point.<br>
<br>
Cheers,<br>
<br>
- Ben<br>
<br>______________________________<wbr>_________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">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-<wbr>bin/mailman/listinfo/ghc-devs</a><br>
<br></blockquote></div><br></div>