Notes from Ben's "contribute to ghc" discussion

Richard Fung minesasecret at
Sun Sep 25 01:43:00 UTC 2016

I suppose I'll take this opportunity to bring this thread back on topic and
have everyone read my thoughts guilt free.

As a newcomer who recently submitted my first patch, I disagree with
Chris's points. I'm just a junior developer who has never worked on a
compiler before, so maybe the experience will be different for people from
other backgrounds. I guess you're allowed to disagree with me even if
you're from a similar background.

In my (short) experience, Github vs Phabricator, using Arc, and the points
mentioned in the linked blog like coding style and comments were all non
issues. Again, this is just my experience and others might feel
differently, but if so I encourage them to raise their points and hopefully
also explain in detail the issues encountered.

For me the only issue was being able to understand the code base. Sadly,
this was actually a huge barrier because, rather embarrassingly, after
months of reading through the code, in the end I only managed to submit a
patch after Simon told me exactly what I needed to do. Even more
depressingly, the other Simon (Marlow) was unhappy because it caused a
performance regression so the patch was rejected! Sad life..

In other words, I found the difficulty in actually being able to contribute
a meaningful patch is far greater than any difficulty in learning to use
the tools and process required to submit a patch.

Of course this is to be expected from a code base as large, old, and
complicated as GHC's, and I'm not too sure what can be done from a
technical standpoint to address this, besides better documentation. From a
process standpoint though, if I didn't have personal assistance from Simon
and Ben (Thank you!!!) I imagine I would have given up much sooner, despite
having been relatively motivated.

I don't know if this would be possible of course considering GHC developers
are very busy as it is, but it would be great if newcomers could be
assigned a mentor to contact when in need of help. Maybe I am just weird,
but I actually felt bad emailing everyone for help, so I would typically go
much longer than comfortable before asking for help. As you can imagine, as
the struggle increases, the likelihood of giving up also does, and I will
admit I thought about giving up many times.

I realize this would probably be difficult to scale, but hopefully as new
developers come, they would also be able to mentor others. I think this is
similar to what is done in the industry by many companies as well.

In summary, difficulty of understanding code base >>> difficulty of using
tools and following documentation.

On Sat, Sep 24, 2016 at 6:29 PM, Christopher Allen <cma at>

> I'd be willing to help with work required to open up GHC development
> more along multiple lines including:
> Bots/automation for Github
> Talking to Rust devs about what works, what doesn't
> Talking to GHC devs about what works, what doesn't,
> comparing/contrasting with other processes such as Rust's
> Papering all this up into a "where we are, where we'd like to go" document
> Writing documentation and tutorials for getting new developers on board
> Manually on-boarding new developers
> I am willing to do this work in addition to my 9-5 work using Haskell,
> the book(s) which are a full-time job unto themselves, and the open
> source work I do.
> I will not do any of this as long as this is the attitude of GHC
> developers. I can not in good conscience encourage people to
> contribute to a project controlled and represented with such hostility
> and dismissiveness. The needs of the community and of new and casual
> contributors have to be taken seriously. This is not for their sake
> alone, it's to ease the workload of the maintainers and to mend the
> worsening culture gap.
> On Sat, Sep 24, 2016 at 8:19 PM, Brandon Allbery <allbery.b at>
> wrote:
> >
> > On Sat, Sep 24, 2016 at 9:08 PM, Manuel M T Chakravarty
> > <chak at> wrote:
> >>
> >> Why are you so hostile to Chris? I don’t think that this is an
> appropriate
> >> way to treat somebody who is making a suggestion in good faith.
> >
> >
> > It may be in good faith. but it's not in good sense. There is a lot in
> the
> > background that made Rust's setup possible, and he's not bringing that to
> > the table, just assuming it'll somehow happen or that everyone else will
> > drop everything for the next few months and make it happen. And I feel
> like
> > he's being really pushy about committing already overworked people to
> this
> > --- and insisting that anyone opposed must have a hidden agenda or
> otherwise
> > cannot possibly have good reason to be opposed. It's not helpful at all;
> > it's basically a good way to stall ghc for the next few months at least.
> >
> > --
> > brandon s allbery kf8nh                               sine nomine
> associates
> > allbery.b at
> ballbery at
> > unix, openafs, kerberos, infrastructure, xmonad
> --
> Chris Allen
> Currently working on
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the ghc-devs mailing list