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