Notes from Ben's "contribute to ghc" discussion

[Christopher Allen]

Why are contributions via Github limited to things that don't require
review? That won't encourage anyone to get started because they know
that as soon as they move on to something substantive, they'll hit the
same brick wall. You can't boil a frog by taking it out of the pot of
lukewarm water and tossing it into the roiling kettle.

Have you looked at how Rust handles contributions to the compiler?

https://github.com/rust-lang/rust

They don't rely on bare Github, they use bots to automate and add
structure in the ways you're trying to wring out of Phabricator.

The automation and community they've built here is above and beyond
anything I've seen in any other community, it is _outstanding_ and it
behooves us to learn what they do and to take it seriously. Rust has
five times the contributors GHC does and the depth of contributions do
not trail off as quickly.

Rust has been around for less time than many popular Haskell libraries!

To see more of how Rust developers and users discuss new features and
improvements, this forum is illuminating:
https://internals.rust-lang.org/

I work with someone that has contributed to GHCJS more than once, but
will not go anywhere near GHC. This is almost entirely because of the
opaque process.

Another: https://github.com/purescript/purescript

94 contributors, only a couple years old, written in Haskell but has
many users who came from JS and don't know any Haskell, used mostly
for frontend work.

Putting aside Github's new code review functionality (which seems fine
but isn't anything terribly impressive), there are lots of ways to
skin the code review cat without putting new contributors in a
typo-fix PR ghetto.


On Sat, Sep 24, 2016 at 6:53 PM, Joachim Breitner
<mail at joachim-breitner.de> wrote:
> Hi,
>
> Am Samstag, den 24.09.2016, 18:46 -0500 schrieb Christopher Allen:
>> Seems reasonable, but much of the consternation over GHC dev process
>> has been about the relative illegibility of it, even for working
>> programmers who've hacked on compilers before. It's concerning to see
>> a list of items about a "contribute to GHC" discussion that seemingly
>> includes nothing that addresses this.
>>
>> Can you point me to any discussions among GHC devs on this since the
>> last time it was raised?
>
> I’m not sure why this proposal is causing unease here? Regular
> contributors are contributors too!
>
> Also, the idea of accepting trivial commits via GitHub (which are then
> pushed by someone with commit access) works much better if the latter
> can be done efficient, i.e. in a fire-and-forget, but still safe and
> checked, mode.
>
> And the list does include a few things that are meant to help new
> contributors:
>  * Accepting contributions where a quick review suffices via
>    GitHub (that’s the item “lightweight pushes”).
>  * Not imposing style guides that people have to learn first
>  * Docker images to quickly get started.
>  * Easier ways of learning about GHC development (by removing old docs,
>    and leverating SO).
>
> That list is not meant to be exhaustive, if you have other ideas how to
> make GHC hacking more accessible, please tell us!
>
> I am under the impression that there is some misunderstanding here,
> because there really is nothing not be wound up about here.
>
> Greetings,
> Joachim
>
>
>
> --
> Joachim “nomeata” Breitner
>   mail at joachim-breitner.de • https://www.joachim-breitner.de/
>   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
>   Debian Developer: nomeata at debian.org
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>



-- 
Chris Allen
Currently working on http://haskellbook.com